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(54) Wireless access to packet*based networks 

(57) Domains are defined to Incorporate a subnet In- 
cluding a plurality of base stations and routers. Base sta- 
tions are used by mobile devices to attach to the wired 
portion of a packet-based network, such as the Internet, 
and exchange pacicets thereover with a correspondent 
node. Local mobility between domain base stations is 
provided by including and updating routing table entries 
at domain routers and base stations for (onrardlng pack- 
ets having a mobile device's address as a destination 
address to the mobile device. Packets are delivered to 
the nDobile device regardless of the domain base station 
to which the mobile device is attached. When a mobile 
device is attached to a base station included within a 
foreign domain, a care-of address is assigned, and 
packets are tunneled for delivery of packets to the rrK)- 
blle devrce. Only one care-of address is required per 
mobile device per foreign domain. Routing table entries 
used for packet delivery are updated on a purely local 
subnet basis within domains, whether home domain or 
foreign domain, making handoffs between base statbns 
substantially transparent to the home agent and the cor- 
respondent node. 
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Description 

RgLD OF THg IMVEWTiON 

[0001] The present inveniion relates to the Internet 
and other pacliet-basec networks and more particularty 
to methods for wireless access to packet-based net- 
works by mobile devices. 

BACKGROUND OF THE INVENTiON 

[0002] Support for wireless access between a corre- 
spondent node and a nnobile device over the Internet Is 
outlined in an Internet Engineering Task Force (IETF) 
proposal entitled 'IP Mobility Support,' C.E. Perkins - 
Editor, Request for Comments 2002 (October. 1996; 
hereinafter 'Mobile IP'). By utilizing Mobile IP. each mo- 
bile device Is always identified by a fixed home address 
and associated home agent, regardless of Its point of 
attachment to the Internet. Packets sent to a mobile de- 
vice, from a correspondent node, are directed to the 
home agent. If the mobile device is away from home, 
the home agent forwards packets within an IP-in-IP tun- 
nel to an assigned care-of address registered with the 
mobile device. Such a two-legged routing scheme is 
known as triangular packet routing. Mobile IP provides 
a reasonably effective framework for macro-mobility; 
that is, allowing mobile users to roam away from a home 
network without disrupting a mobile user's applications. 
However. Mobile IP does not effectively support micro- 
mobility, that is. handoffs of a mobile device between 
base stations, each of which covers only a very small 
geographic area. This is because each handoff of a mo- 
bile device to a base station not attached or linked via 
a node hosting the home agent requires the mobile de- 
vice to notify the home agent of its associated care-of 
address regarding the mobile device's new point of at- 
tachment. Therefore, the use of Mobile IP results in 
messaging and signaling delays and inefficient packet 
delivery paths to the mobile device. 
[0003] When the mobile device is in its home network 
(i.e. - the same network in which the mobile device's 
home agent is located), packets destined for the mobile 
device are intercepted by the home agent. The home 
agent routes the packets as normal IP packets and sent 
to the Local Area Network to which the mobile device Is 
normally attached. Therefore. Mobile IP does not sup- 
port any mobility within the local subnet. II a mobile de- 
vice changes its point of attachment within a local sub- 
net, the change must be managed by either link layer 
modification techniques, or by broadcasting packets 
destined to the mobile device to all base stations at- 
tached to the local subnet. Managing the link layer may 
result in unacceptable delays and packet loss while 
broadcasting packets to all base stations is an inefficient 
use of bandwidth. 

[0004] Recently an extension to the Mobile IP protocol 
emerged in a draft Internet Engineering Task Force 



(IETF) proposal entitled 'Route Optimization in Mobile 
IP." C.E. Perkins - Editor. Internet Draft - Work in 
Progress (November. 1997). The route optimization ex- 
tcnsksn proposes a means in whch packets may be 
5 routed from a correspondent node to a mobile device 
away from home without first being forwarded to a home 
agent. Route optimizatbn extensions provkJe a means 
for the correspondent node to cache a binding associ- 
ated with the mobile device and then tunnel packets di- 
10 rectly to the care-of address indicated in that binding, 
thereby bypassing the mobile device's home agent. Uti- 
lizing the proposal, packets are forwarded from an old 
base station foreign agent to a new base station foreign 
agent to reduce disaiption during handoff. However, a 
15 mobile device's care-of address is nonetheless changed 
each time the mobile device is handed off between base 
stations. Although route optimizatkjn is proposed as a 
scheme for improvement in mtero-mobility. route optimi- 
zation still requires undesirable notifications to the home 
20 agent and con^espondent node for each handoff of the 
mobile device. Such frequent notification not only in- 
creases the amount of control traffic generated, but also 
places an unnecessary processing burden upon a fixed 
host which may be providing services to hundreds of 
25 fixed and mobile hosts. Until notification of a handoff is 
completed to the home agent and correspondent node, 
packets destined for the mobile device are fonwarded 
from the old base base station foreign agent to the new 
base station foreign agent. During the required round 
30 trip messaging time between the home agent and the 
correspondent node, packets follow an inefficient deliv- 
ery path resulting in dismptlon to user traffic. 

fitJMMARY OF THE INVENTION 

35 

[0005] Local mobility within a subnet is supported by 
classifying wireless base stations, and the routers used 
to forward packets to those base stations, within defined 
domains. Domains are typically defined to Incorporate 

40 a subnet having a plurality of base stations. Base sta- 
tions are used by nrK>bile devices to attach to the wired 
portion of a packet-based network, such as the Internet, 
and exchange packets thereover with a correspondent 
node. A home domain is a subnet in which a domain 

->5 node hosts a home agent of the mobile device. A foreign 
domain is any domain to which the mobile device is at- 
tached, other than the home domain. Packets sent from 
the correspondent node to the mobile device have a 
packet destination address corresponding to the mobile 

50 device. The mobile device retains this address for the 
duration of time it is powered up and attached to the In- 
ternet via any base station. Therefore, packets destined 
for the mobile device are always routed to the home do- 
main corresponding to the mobile device. 

55 [0006] U the mobile device is attached through a base 
station Included within the home domain, packet tun- 
neling is not required since selected home domain rout- 
ers and routing capable base stations maintain a routing 
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table entry for the mobile device. The routing table en- 
tries are established aruj updated via path setup 
schemes to convey packets destined for the mobile de- 
vice along the proper established path through the do- 
main routers and base stations, regardless of the do* 
main base station through which the mobile device is 
attached. 

[0007] However, if the mobile device is attached 
through a base station included within a foreign domain, 
the home agent corresponding to the mobile device In- 
tercepts packets having the mobile device's address as 
a destination address. A care-of address is assigned to 
the mobile device for the duration of time it is powered 
up and attached to the Internet via any base station in- 
cluded within the instant foreign domain. The home 
agent tunnels packets destined for the mobile device to 
the care-of address for the instant foreign domain. A sin- 
gular care-of address is used when the mobile device Is 
attached through any base station included within the 
instant foreign domain, since host based routing in the 
instant foreign domain is maintained and updated for 
router and base station routing table entries via path set- 
up messages. 

[0008] We have observed that rrx^bility is typically a 
localized phenomenon; that is, the majority of handoffs 
from one base station to another occur when both the 
new and old base stations are incorporated within the 
same subnet. Therefore, for the majority of mobile de- 
vice handoffs. local routing table entries in selected rout- 
ers within the domain are updated, but the mobile device 
address and/or care-of address utilized remain the 
same. As a result of this observation and the application 
of the present invention as a mobility solution, handoff 
notifications to nodes outside of the local domain or sub- 
net, such as to the home agent and the correspondent 
node, are substantially minimized, making the majority 
of mobile device handoffs between base stations trans- 
parent to the home agent and the correspondent node. 
In contrast, the aforementioned route optimization ex- 
tension to Mobile IP not only requires notification to the 
home agent and the correspondent node for each hand- 
off of a mobile device between base stations, but also 
requires the assignment of a new care-of address for 
each handoff outside of the home network, whether or 
not the base stations involved are both incorporated 
within the same subnet. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0009] A more complete understanding of the present 
invention may be obtained from consideration of the fol- 
lowing description in conjunction with the drawings in 
which: 

FIG. 1 illustrates an architecture used to provide 
Mobile IP wireless access to Internet Protocol (IP)- 
based networks from nrwbile devices; 
FIG. 2 illustrates the donnain -based architecture for 



a Handoff-Aware Wireless Access Internet Infra- 
structure (HAWAII), in accordance with the present 
invention: 

FIG. 3 is an exemplary flow diagram of the process 
s steps performed at a Dynamic Host Configuration 
Protocol (DHCP) sen/er for a domain utilizing a HA- 
WAII domain-based architecture, the DHCP sender 
not using a Dynamic Home Optimization; 
FIG. 4 is an exemplary flow diagram of the process 
10 steps performed at a Dynamic Host Configuration 
Protocol (DHCP) sen/er for a domain utilizing a HA- 
WAII domain-based architecture, the DHCP sen/er 
using a Dynamic Home Optimization; 
FIG. 5 is an exemplary flow diagram of the dorriain- 
is based process steps performed during a mobile de- 
vice power down, whether or not utilizing a Dynamic 
Home Optimization, and in accordance with the 
present invention; 

FIG. 6 is a block dagram Illustrating an exemplary 
20 embodiment of a domain router hosting a Dynamic 
Host Configuratkxi Protocol (DHCP) sen/er and a 
home agent, in accordance with the present inven- 
tion; 

FIG. 7 is a diagram of an exemplary structure for 
25 Information Element fields associated with a refresh 
path setup message, in accordance with the 
present invention; 

FIG. 8 is a diagram of an exemplary structure for 
Informatbn Element fields associated with a power 
30 up path setup message, in accordance with the 
present invention; 

FIG. 9 is a diagram of an exemplary structure for 
Information Element fields associated with a hand- 
off path setup message, in accordance with the 

35 present invention; 

FIG. 10 is a flow diagram for an exemplary method 
utilized by routers in a domain-based HAWAII archi- 
tecture subnet for processing a power up path setup 
message; in accordance with the present invention; 

40 FIG. 11 illustrates a power up path setup message 
processing sequence in an exemplary domain uti- 
lizing HAWAII domain-based architecture, in ac- 
cordance with the present invention; 
FIG. 12 is a flow diagram for an exemplary method 

45 utilized by routers in a donriain -based HAWAII archi- 
tecture subnet for processing a refresh path setup 
message, in accordance with the present invention; 
FIG. 13 is a flow diagram lor an exemplary method 
utilized by routers in a domain -based HAWAII archi- 

50 tect u re subnet for processing a new-to-okj path set- 
up message, in accordance with the present inven- 
tion; 

FIG. 14 illustrates an exemplary new-to-old path 
setup scheme processing sequence in an exempla- 
55 ry domain utilizing HAWAII domain-based architec- 
ture, in accordance with the present invention; 
FIG. 15 illustrates an exemplary new-to-old path 
setup scheme processing sequence in an exempla- 
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ry domain utOizing HAWAII domain-based architec- 
ture, vuherein a new base station is directly couple 
to an old base station, in accordance with the 
present invention: 

FIG. 1 6a is a flow diagram for an exemplary method 
utilized by domain routers processing a new-t^td- 
to^ew phase one handoff path setup message, in 
accordance with the present invention: 
FIG. 1 6b is a flow d'agram for an exemplary method 
utilized by domain routers processing a new-to-old- 
to-new phase two handolt path setup message, in 
accordance with the present invention; 
FIG. 17 illustrates an exemplary embodiment of a 
new-to-old-to-new path setup scheme processing 
sequence in an exemplary domain, in accordance 
with the present invention; 
FIG. 1 8 is a block diagram illustrating an exemplary 
embodiment of a domain router having a routing ta- 
ble, in accordance with the present invention; 
FIG. 1 9 Is a diagram illustrating the Mobile IP stand- 
ard method utilized for tunneling IP packets from a 
mobile devfce's home agent to the nnobile device's 
foreign agent; 

FIG. 20 is a diagram illustrating a lunneling optimi- 
zation, in accordance with the present invention; 
FIG. 21 is a chart of a tcpdump trace for a conven- 
tional Mobile IP tunneling of packets; 
FIG. 22 is a chart of a tcpdump trace for packet de- 
livery from a home agent to a foreign agent utilizing 
a tunneling optimization scheme, in accordance 
with the present invention; 
FIG. 23 is a flow diagram Illustrating an exemplary 
procedure for implementing a lunneling optimiza- 
tion at a node hosting a home agent, in accordance 
with the present invention; and 
FIG. 24 Is a flow diagram illustrating an exemplary 
procedure for implementing a lunneling optimiza- 
tkjn at a foreign agent co-bcated with a correspond- 
ing mobile device. 

DETAILED DESCRIPTION 



[0010] Although the present invention is illustrated 
and described herein as an embodiment utilized lor 
wireless access to Internet Protocol (IP)-based net- 
works, such as the Internet or intranets, the embodiment 
Is merely illustrative and should not be constmed as be- 
ing so limited. The present invention is equally applica- 
ble for wireless access to any packet-based network 
from a mobile device. 

[0011] Referring to FIG. 1 . there is shown an exem- 
plary architecture currently used to provide Mobile IP 
wireless access to Internet Protocol {lP)-based net- 
works from mobile devices. A correspondent node 110 
is illustrated accessing the Internet 100 via a sen/ice 
provider 112. A correspondent node nnay be either mo- 
bile or stationary. A mobile user utilizing a mobile device 
1 14 is illustrated In proximity with base station BSl and 



maintaining an established connection with base station 
BSl . A mobile device is a wireless host or router that is 
capable of changing its point of attachment from one 
network or subnet to another. Associated with the mo- 
5 bile device 114 is a home agent 118. the home agent 
118 illustrated accessing the Internet 100 via a setv\ce 
provider 116. A home agent is implemented in a node 
or router and tunnels packets for delivery to the mobile 
devce when it is away from home, and maintains cur- 
io rent kxation informatton for the mobile device. 

[0012] Also illustrated are routers attached to the In- 
ternet 100 used to route packets between the Internet 
and a plurality of base stations. Specifically router Rl 
Is shown Interlacing routers R2 and R3. Router R2 is 
IS shown interlacing base stations BSl and BS2. Similarly, 
router R3 is shown interfacing base stations BS3 and 
BS4. Within the context of ivtobile IP. and throughout the 
remainder of the description of the present invention, 
base stations Include all of the capabilities associated 
20 with conventional wireless base stations, and in addi- 
tion, include the capabilities associated with convention- 
al routers. This dual-funcik?nality is accomplished with 
either an Integrated router and base statton solution, or 
in the alternative, with separate router and base station 
25 components interfaced appropriately to exchange pack- 
ets between the two. With regard to the latter, the router 
and base station components ar© typically co-located 
within a cpmnrvan facility, although co-locatkxi is not a 
requirement. 

30 [0013] The IP mobility support provided by Mobile IP 
is characterized in that each mobile device Is always 
identified by its home address, regardless of its current 
point of attachment to the Internet. While situated away 
from its home, a mobile device is also associated with 
3S a care-of address, whfch provides information regarding 
its current point ol attachment to the Internet. Mobile IP 
requires registration of the care-of address with the 
home agent. The home agent tunnels packets destined 
for the mobile device within I P-in-IP encapsulated pack- 
40 ets to the care-of address. When an IP-in-IP packet ar- 
rives at the care-of address, the appended IP address 
is removed and the original packet data is then delivered 
to the appropriate mobile device. The care-of address 
is the termination point of a tunnel toward a mobile de- 
45 vice for packets forwarded to the mobile device while it 
is away from home. 

[0014] As an example of the operation of the l\toblle 
IP scheme, assume that mobile device 114 changes its 
point of attachment (via handoffs) to the Internet from 
so base station BSl through base station 834 as the mo- 
bile device moves sequentially and incrementally from 
mobile device 114 position 1 through 4, as illustrated in 
FIG. 1. While positioned in proximity to base station 
BSl, packets sent from the correspondent node 110 to 
ss the mobile device 114 are first sent to the mobile de- 
vice's home agent 113. The home agent 118 tunnels 
each packet to the corresponding address for base sta- 
tion BSl . When the mobile device is handed off to base 
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station BS2. its point of attachment to the Internet is 
changed to the address corresponding to base station 
BS2. The home agent now tunnels packets destined for 
the mobile device 114 to base station BS2. In order to 
implement this routing change, notification must be sent 
to the home agent 118 that the point of anachment has 
been changed. When the home agent receives this no- 
tification, it updates an established routing table so that 
subsequent packets destined for the nx}bile device 114 
are tunneled to base station BS2. Handoffs to base sta- 
tions BS3 and BS4. are treated simiiarty. Such a delivery 
scheme is known as triangular routing. Mobile IP and 
the triangular routing scheme utilizing a home agent is 
effective as a means for providing macro-mobility, that 
is, as a mobile device changes its point of attachment 
to the Internet from one IP subnet to another. However, 
Mobile IP is a less effective means for providing micro- 
mobility, that is, as handoffs occur amongst wireless 
transceivers within a common subnet, each of which 
covers only a very small geographic area. 
[001 5] Recently an extension to the Mobile IP protocol 
emerged in a draft Internet Engineering Task Force pro- 
posal entitled 'Route Optimization in Mobile IP,* C.E. 
Perkins - Editor, Internet Draft - Work in Progress (No- 
vember, 1997). The route optimization extension pro- 
poses a means in which packets may be routed from a 
correspondent node to a mobile device without first be- 
ing forwarded to a home agent. The route optimization 
extension provides a means for the correspondent node 
110 to cache a binding associated with the mobile de- 
vice 114 and then send packets directly to the care-of 
address indicated in that binding, thereby bypassing the 
mobile device's home agent 118. Utilizing the proposal, 
packets are forwarded from an oW base station foreign 
agent to a new base station foreign agent to reduce dis- 
ruption during handoff. However, the mobile device's 
care-of address is nonetheless changed each time the 
mobile device is handed off between base stations. For 
example, assume that the mobile device 11 4 is handed 
off from base station BSl (old base station) to base sta- 
tion BS2 {new base station). Because the route optimi- 
zation extension binds the care-of address to the current 
foreign agent (associated with the servicing base sta- 
tion), the care-of address is changed from BSl to BS2. 
Such a scheme is an improvement in micro-mobility, but 
still requires undesirable notifications to the home agent 
1 1 8 and correspondent node 1 10 for each handoff of the 
mobile device 114. 

[<X)1 6] When the mobile device is in its home network 
(i.e. - the same network in which the mobile device's 
home agent is located), packets destined for the mobile 
device are intercepted by the home agent. The home 
agent routes the packets as normal IP packets and sent 
to the Local Area Network to which the mobile device is 
norrr^aily attached. Therefore. Mobile IP does not sup- 
port any mobility within the local subnet, whether or not 
the route optimization extension is utilized. If a mobile 
device changes its point of attachment within a k)cal 



subnet, the change must be managed by either link layer 
modification techniques, or by broadcasting packets 
destined to the mobile device to all oase statons at- 
tached to the kxal subnet. Managing the link layer may 
5 result in unacceptable delays and packet toss while 
broadcasting packets to all base stations is an inefficient 
use of bandwidth. 

LOCAL MOBIUTY DOMAINS 

10 

[001 7] We have recognized that today's wide-area IP 
network is typically divided into subnets which are man- 
aged by independent entities, each entity operating 
within its respective subnet using independent local pro- 
15 tocols, while agreeing upon a standard protocol for in- 
terlacing outside of each respective subnet. The present 
invention takes advantage of the natural independence 
and autonomy associated with an entity controlled sub- 
net (for example, a cellular service provider having a 
20 root router accessing the Internet and servicing a plu- 
rality of base stations) by classifying and defining a plu- 
rality of domains. Each domain, in effect, is a local sub- 
net. Each domain maintains a root router to access the 
Internet, and all routers within a domain utilize a com- 
as mon local protocol. 

[0018] The present inventkjn, in classifying routers 
having a common root router within defined domains, 
leverages the fact that the mobility of a mobile user be- 
tween base statbns is typically a localized phenomenon 

30 (i.e. - that most handoffs occur between neighboring 
base stations having an adjacent proximity and which 
are owned and operated by a common service provkJer 
attached through a common root router to the Internet). 
[0019] Utilizing the present Inventksn. when a mobile 

35 device in transit is handed off from one base station with- 
in the assigned home domain to another base statk)n 
within the assigned home domain, selected routers with- 
in the home domain have their associated routing tables 
updated, using specialized path setup messages on a 

40 purely kx:al level (i.e. • routers within the home domain 
only), to reflect the change. Thus, messaging and sign- 
aling between routers are minimized since updates oc- 
cur only on a local domain-based level and only for se- 
lected routers (i.e. - only those routers for which routing 

4S table updates are required to be made). Also, when us- 
ing Mobile IP either packets must be broadcast to all the 
base stations included in a home domain, or link layer 
addressing must be used to address a single base sta- 
tion; whereas the present inventwn updates the home 

so domain router's individual routing tables to direct a pack- 
et to a single base statbn. Since IP layer routing may 
be used end-to-end. IP-layer QoS mechanisms may be 
utilized in conjunction with the present inventton. 
[0020] However, when a mobile device in transit is 

55 handed off from one base statbn within the assigned 
home domain to a base station in a foreign domain, 
packets are tunneled from the home agent to a care-of 
address assigned to the mobile device within the foreign 
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domain. Mcro-mobtBty within the foreign domain Is ac- 
compnshed by keeping the same care-of address (or the 
mobile device for the entire time the mobile device is 
attached to the Internet through base stations associat- 
ed with that foreign domain, regardless of the number 
of handoff s performed between base stations associat- 
ed with that domain. Instead, as was described in con- 
junction with handoffs performed within the home do- 
main, selected routers within the foreign domain have 
their associated routing tables updated, using special- 
ized path setup messages on a purely local level {i.e. - 
routers within that foreign domain only), to reflect the 
change. Thus, messaging and signaling between the 
foreign agent and the home agent are minimized since 
updates occur only on a local domain-based level and 
only for selected routers (i.e. - only those routers for 
which routing table updates are required to be made. 
Therefore, handoffs between base stations in a foreign 
domain are substaniiaity transparent to the mobile us- 
er's home agent and correspondent node. 
[0021] FIG. 2 illustrates the domain-based architec- 
ture lor a Handoff -Aware Wireless Access Internet In- 
frastructure (HAWAII), in accordance with the present 
invention. In order to implement HAWAII, the wired ac- 
cess portion of the wireless network is divided into do- 
mains, each domain having a common root router 
through which all packets destined for mobile users con- 
nected to a base statkjn within that domain are forward- 
ed. Specifically, shown in FIG. 2 is a wired access por- 
tion of a wireless network divided into two domains. 
Domaini andDomain2. Domaini Is comprised of a root 
router through which all packets destined tor mobile de- 
vices connected to base stations BS5, BS6. or BS7 are 
routed. Illustratively, routers R4 and R5 are shown as 
downstream routers utilized within Domaini to forward 
packets to the appropriate base station. It is assumed, 
in this exemplary embodiment, that Domaini is defined 
to encompass a subnet representing the home domain 
servicing a mobile device 114. A home agent 152 Is In- 
corporated at root router 150. Although the instant em- 
bodiment Is illustrated and described as having the 
home agent 152 implemented within the root router 1 50 
utilizing the capabilities of the processor and memory 
residing in root router 1 50. it would be apparent to those 
skilled in the art to alternatively implement the home 
agent 152 using a separate co-kxated processor and 
memory, such as that available in a personal computer. 
Furthermore, the home agent need not be implemented 
in conjuncton with the root router at all; that is. the home 
agent may be Implemented in any local router or node 
capable of communicating with the other routers (includ- 
ing base stations) within the home domain. Domatn2 is 
presented as an exemplary subnet representing a sec- 
ond' domain servicing base stations not incorporated 
within Donr^im. Domaln2 is therefore representative of 
a foreign ctomain. Incorporated within Domain2 are a 
plurality of routers servicing one or more base stations. 
For illustrative purposes only, router R6 is shown as a 



root router for Domain2 and BS8 is shown as one of the 
base stations sen/iced through the routers of Domain2. 
It should also be noted that router R6 may be enabled 
with home agent and root router functionality for those 
5 mobile devices having Oomain2 as th eir assigned home 
domain, thus Domain2 would be a foreign domain to 
those mobile devices having home agent functk^nality 
residing within root router 1 50, whereas Domaln2 woukJ 
concurrently be a home domain to those mobile devces 
10 having home agent functionality residing within router 
R6 (not shown). Each subsequent domain (no others 
illustrated In FIG. 2) provides Internet access for one or 
more base stations attached to the Internet 100 through 
a common root router. 
IS [0022] As a mobile user operating a mobile devk^e 1 1 4 
moves about within a domain, whether within the home 
domain or a foreign domain, the mobile device's IP ad- 
dress remains unchanged. For instance, assuming that 
a mobile device 1 1 4 Is first sen/iced by base statkDn BS5 
20 and Is then handed off to base station BS6 and then to 
BS7, the nroblle device's IP address remains the same. 
The home agent for the mobile user and the correspond- 
ent node are shielded from the user's mobility while the 
devkie is connected through any base station with'm that 
25 domain. Establishing packet delivery to the mobile de- 
vice from a now base station within a domain is accom- 
plished by using a specialized path setup scheme, sub- 
sequently described, which updates selected host 
based routing tables in selected routers within the do- 
30 main. Advantageously, since each domain is identified 
as a local subnet, there are no changes or updates re- 
quired to the routing entries in the backbone routers out- 
skje of each domain. This method Is distinctly different 
from the method used for the Route Optimization exten- 
35 sion to Mobile IP, previously described, in whfch the mo- 
bile device's care-of address is changed each time the 
mobile device is handed off between neighboring base 
stations, but routing entries contained within individual 
routers remain unchanged. 
40 [0023] When a mobile device 1 1 4 changes its point of 
attachment from a base station associated with a first 
domain (with the first domain being either the home do- 
main or a foreign domain) to a base statton associated 
a second domain (with the second domain being any 
45 foreign domain, but not the home domain, since tun- 
neling is not required when a mobile device's point of 
attachment is from any base siatksn included within the 
home domain), packets are forwarded to the mobile de- 
vce In the new (second) domain, from the home agent, 
so using a protocol for packet tunneling, one such protocol 
being Mobile IP. For example, if mobile device 114 Is 
handed off from base station 6S7 (wired to the Internet 
through Domaini ) to base station BS3 (wired to the In- 
ternet through Oomain2), then the home agent 152 at 
ss the root router 1 50 in the home domain (Domain 1 ) be- 
gins encapsulating packets and tunnels them to the new 
care-of address obtained by the mobile device when 
handed off to a Domain2 base station. Thus, applica- 
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tions can continue to use the same IP address without 

disrupiion. 

[0024} In order to provide a guaranteed Quality ot 
Sen/ice (QoS) {or delivery oi packet nows to mobile us- 
ers, each router along the packet flow path specifies a 
predetermined level of QoS associated with each pack- 
et so inat adequate router resources are reserved. One 
method lor performing this classification functkin is 
Ihrougn the use of packet header fieWs specifying a lev- 
el ol QoS associated with each packet. Such a scheme 
is prcscniod in a paper by T.V. Lakshman and D. Stili- 
adis cniitlod 'High Speed Policy-based Packet Forward- 
ing Using Ellicient Multi-dimensional Range Matching," 
in the Proceedings ol ACM SIGCOMM. 1998 and in a 
paper by V Srinivasan. G. \ferghese, S. Suri. and M. 
Waldvogci entitled 'Fast Scalable Algorithms for Level 
Four Switching.' m the Proceedings of ACM SIGCOMM. 
1998. 

[0025] However, using the local mobility domains im- 
plemented in HAWAII, and in accordance with the 
present invention, packets transmitted from a corre- 
spondent node to a mobile device are uniquely identified 
by the packet's destination address, which is the mobile 
device's home address (if the mobile device is attached 
to the network through a base station within its home 
domain) or the mobile device's co-located care -of ad- 
dress (if the mobile device is attached to the network 
through a base statk^n which is incorporated in a foreign 
domain). Thus, providing QoS guarantees for packets 
on a per-fiow basis within a local mobility domain is 
greatly simplified when compared to providing that serv- 
ice utilizing the Mobile IP scheme (in v\/hich packets are 
tunneled to a care-of address corresponding to a serv- 
icing base station rather than the mobile device itself). 
[0026] Mobile device users in the HAWAII local mo- 
bility domain scheme are assigned a dynamic IP ad- 
dress through a Dynamic Host Configuration Protocol 
(DHCP) server. As the device is handed off between 
base stations within the domain, the device's assigned 
IP address does not change. Therefore, users outside 
the domain do not perceive the user's mobility. This ap- 
proach makes use of two IP addresses assigned to each 
mobile device; one assigned to the mobile device in the 
home don^in and a second assigned when the mobile 
device is connected through a base station associated 
with a foreign domain. Although the use of multiple IP 
addresses exacerbates the current limited availability of 
IP addresses, the limited IP address problem will be- 
come moot once the use of IP version 6 becomes ubiq- 
uitous. 

[0027] Altematively, however, an optimization that 
woukj consen/e available IP addresses is called Dy- 
namic Home Optimization. Us'mg Dynamic Home Opti- 
mization, a mobile device doss not have any address 
assigned to it until it is powered up. We have recognized 
that mobile devices as data clients typically initiate a 
transaction with a server, such as a web server or mail 
sen/er. and therefore do not require a permanent IP ad- 



dress. Upon initial power up. the mobile device is as- 
signed a 'dynamtt permanent address' from the Dy- 
namic Host Ojnfiguratran Protocol (DHCP) sender vrith- 
in the domain in which the power up occurs. This domain 
5 then becomes the home domain for the mobile device. 
Therefore, the mobile device neither has a permanent 
address nor is the nriobile device registered permanently 
within any one domain. If the rTK)bile device changes its 
point of attachment to a base statwn in a domain other 
10 than the one in which it is powered up, the mobile device 
is assigned a second IP address by the DHCP server 
residing in the new domain. This new second address 
is the mobile device's co-located care-of address. When 
the device is powered down, the nrablle device relin- 
is quishes its dyrwmic permanent address (assigned from 
the DHCP server in the domain in which it powered up) 
and the co-kx:ated care-of address (assigned from the 
DHCP of the domain to which it is attached at the time 
of power down). Upon the next power up, the nrx)bile 
20 device is assigned a new dynamic permanent address 
in the domain it attaches to when it powers up. 
[0028] FIG. 3 is an exemplary flow diagram of the 
process steps performed at a Dynamic Host Configura- 
tion Protocol (DHCP) server for a domain in order to im- 
25 plement the domain-based HAWAII method of the 
present invention, without Dynamic Home Optimization. 
In step 1 70, a mobile device is assigned a home address 
for use in the home domain. The DHCP sender may be 
implemented within the root router utilizing the capabil- 
30 ities of the processor and memory residing in the root 
router, although it would be apparent to those skilled in 
the art to altematively implemientthe DHCP senrer using 
a separate co-located processor and memory, such as 
that available in a personal computer. Furthermore, the 
35 DHCP senrer need not be implemented in conjunctfon 
with the root router at all; that is, the DHCP sen/er may 
be implemented in any local router or node capable of 
communicating with the other routers (including base 
stations) within the domain. Once the mobile device 
40 powers up. in accordance with step 1 72. it is determined 
whether the mobile devk:e is connected through a base 
station included within the home domain, in accordance 
with step 174. If the mobile device is attached through 
the home domain, then in accordance with step 173, 
45 host based routing is established within the home do- 
main utilizing a specialized path setup scheme (subse- 
quently described). 

[0029] However, if the mobile device is attached 
through a foreign domain (a domain other than the home 

so domain), then in accordance vinth step 176. the mobile 
device acquires a care-of address from the DHCP send- 
er supponing the foreign domain. In accordance with 
step 180. host based routing in the foreign domain is 
then established using a specialized path setup 

55 scheme. Once a care-of address is acquired and the 
path setup scheme is established, packets destined for 
the mobile device are tunneled to the mobile device's 
co-located care-of address from the home domain root 
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router, in accordance with step 182. In accordance with 
Step 1 34, as long as a mobile device Is handed ofl to 
base stations included within its current domain, no ac- 
tion is taken (other than generating a subsequently de- 
scribed handotf path setup message). If however, the 
mobile device is handed ofl to a base station affiliated 
with a new domain, then the current careof address is 
released, m accordance with step 1 86. The flow diagram 
is then reentered just prior to step 1 74 where a check of 
mobile device attachment to the home domain is per- 
formed. This procedure continues for each subsequent 
handoff until the mobile device powers down. 
[0030] FIG. 4 is an exemplary flow diagram of the 
process steps performed at a Dynamic Host Configura- 
tion Protocol (DHCP) sen/er for a domain in order to im- 
plement the domain-based HAWAII method which uti- 
lizes Dynamic Home Optimization. The procedure is 
similar to that described in conjunction with FIG. 3 ex- 
cept that the mobile device is not assigned a permanent 
home address. Rather, the concept of a dynamic per- 
manent home address is inuoduced. as previously de- 
scribed. In accordance with step 200, the mobile device 
first powers up and establishes a link with the servicing 
base station prior to obtaining an address within the do- 
main. After establishing the link, the domain's DHCP 
server assigns a dynamic permanent home address to 
the mobile device, in accordance with step 202. Using 
Dynamic Home Optimization, the domain in which the 
mobile device powers up becomes the mobile devices 
home domain. A determination is then made, in accord- 
ance with step 204. whether the mobile device is con- 
nected through a base station included within the home 
domain. Since the mobile device is always attached to 
a base station included within the home domain follow- 
ing initial power up when using Dynamic Home Optimi- 
zation, then in accordance with step 206, host based 
routing is established within the home domain utilizing 
a specialized path setup scheme. In accordance with 
step 21 4, as long as a mobile device handed off to base 
statwns included within the home domain, no action is 
taken (other than generating a subsequently described 
handoff path setup message). If however, the mobile de- 
vice is handed off to a base station affiliated with a for- 
eign domain, then the flow diagram is reentered just pri- 
or to step 204 where a check of nfK>btle device anach- 
ment to the home domain is performed. The care-of ad- 
dress referred to in step 2i6 is not released since the 
mobile device has not yet been assigned one. 
[(X)31l In accordance with step 204, if the mobile de- 
vice is attached to a foreign domain, then In accordance 
with step 208. the nnobile device acquires a care-of ad- 
dress from the DHCP server supporting the foreign do- 
main. In accordance with step 210, host based routing 
in the foreign domain is then established using a spe- 
cialized path setup scheme. Once a careof address is 
acquired and the path setup scheme Is established, 
packets destined for the mobile device are tunneled to 
the mobile device's co-located care-of address irom the 



home domain root router, in accordance with step 21 2. 
In accordance with Step 2i 4. as long as a mobile device 
is handed off to base statons included within its current 
domain, no action is taken (other than generating a sub- 

5 sequently descnbed handoff path setup message). If 
however, the mobile device is handed off to a base sta- 
tion affiliated with a new domain, then the current care- 
of address is released, in accordance with step 21 6. The 
flow diagram is then reentered just prior to step 204 

10 where a check of mobile device attachment to the home 
domain is performed. This procedure continues for each 
subsequent handoH until the mobile device powers 
down. 

[0032] FIG. 5 is an exemplary flow diagram of the do- 

IS main-based process steps performed during a mobile 
devce powerdown, whether or not utilizing the Dynamic 
Home Optimization, and in accordance with the present 
invention. The mobile device maintains a link via its cur- 
rent base station, in accordance with step 230. In ac- 

20 cordance with step 232, if the Dynamic Host Configura- 
tion Protocol (DHCP) servers utilize Dynamic Home Op- 
timization, then a determination is made as to whether 
the mobile device is attached to the Internet via its home 
domain, in accordance with step 240. If the mobile de- 

2S vice, at time of power down, is attached to the Internet 
via a base station within a foreign domain, then in ac- 
cordance with step 244, the dynamic permanent home 
address and the assigned care-of address are returned 
to their respective DHCP servers for subsequent use 

30 and assignment. If however, the mobile device, at time 
of power down, is attached to the Internet via a base 
station within the home domain, then, in accordance 
with step 242, only the dynamic permanent home ad- 
dress is returned to its respective DHCP sen/er for sub- 

35 sequent use and assignment since the mobile device is 
not assigned a care-of address while in its home do- 
main. 

[0033] If however, the Dynamic Host Configuration 
Protocol (DHCP) sen/ers do not utilize Dynamic Home 

40 Optimization, then a determination is made as to wheth- 
er the mobile device is attached to the Internet via its 
home domain, in accordance with step 234. It the mobile 
device, at time of power down, is attached to the Internet 
via a base station within a foreign domain, then in ac- 

45 cordance with step 239, the assigned care-of address 
is returned to its respective DHCP sen/er for subsequent 
use and assignment, II however, the mobile device, at 
time of powerdown, is attached to the Internet via a base 
station within the home domain, then, In accordance 

so with step 236. no action Is taken. This is because when 
not using the Dynamic Home Optimization option, the 
permanent home address is not returned to its respec- 
tive DHCP server since the home address is not dynam- 
ically assigned, but rather permanently registered with 

55 the mobile device at the home DHCP server. 

[0034] FIG. 6 is an exemplary embodiment of a do- 
main router 260 hosting a Dynamic Host Configuration 
Protocol (DHCP) server 272 and a home agent 270. Do- 
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main routers are comprised of a plurality of ingress ports 
(or intenaces) 262 for receivir^g packets from the previ- 
ous node and a plurality of egress pons (or Interfaces) 
264 for sending packets to a next hop. It is also known 
to those skilled in the art that interfaces may be bi-direc- 
tional as well. That is. an interface may act as both an 
ingress and egress interface. Additionally, routers each 
Include a processor 266 arxJ memory 268. The process- 
ing and memory resources resident at each router ena- 
ble the provisioning of router functions and services 
such as: implementing forwarding algorithms, queuing, 
signaling, messaging, implementing router forwarding 
tables, as well as other standard and supplemental rout- 
er functions and sen/ices. The domain router 260 illus- 
trated in FIG. 6 shows a DHCP server 272 and home 
agent 270 implemented utilizing the resources of the 
processor 266 and memory 268. Typically, the domain 
router 260 In which the DHCP server 272 and home 
agent 270 are implemented is the domain root router, 
but this arrangement is not required by necessity, as 
previously described. It would be apparent to those 
skilled in the art to alternatively implement the home 
agent and DHCP server in any local router or node ca- 
pable of communicating with the other routers (including 
base stations) within a domain. Furthermore, those 
skilled in the an would also realize that the home agent 
and DHCP seo/er may be implemented outside of the 
router itself using a separate co-kxated processor and 
memory, such as that available in a personal computer, 
with appropriate communications provided with the do- 
main root router. Implementation of a foreign agent with- 
in a router, when required, is also performed in like man- 
ner. 

[(X)35] It is noted that the host based routing architec- 
ture of the present invention effectively provides for sys- 
tem scalability. For example, ihe number of routing en- 
tries included within domain routing tables is dependent 
upon the number of mobile users active within the do- 
main. Typically, each wireless base station may be lim- 
ited to a hundred or so powered up users, due to the 
limited wireless bandwidth spectrum available. Since 
current routers support on the order of ten thousand 
router entries, domain size Is designed to include ap- 
proximately one hundred base stations. Since the cov- 
erage area of one hundred base stations is quite large 
(a radius of 20 km^ to 500 km2 depending whether lo- 
cated in a metropolitan or rural locatk^n), the majority of 
user movement is within a single domain, resulting in 
substantially transparent mobility with respect to home 
agents and con-espondent nodes. Therefore, scalability 
is ensured: (t) through the inherent capabilities of current 
routers to process on the order of ten thousand routing 
entries, and (i7) utilizing an appropriate domain size so 
as to limit the maximum number of routing entries need- 
ed to be maintained by routers within each domain. In 
contrast, non-domain Internet backbone routers need 
only maintain subnet (domain) based routing entries. 



PATH SETUP SCHEMES 

[0036] As previously introduced, the host based do- 
main oriented HAWAII method utilizes three basic types 

5 of path setup messages to establish, provide, and up- 
date domain routers for packet delivery management to 
a mobile user. The first type is a power up path setup 
message, initiated and sent by a mobile devce during 
mobile device power up to first establish a router packet 

10 delivery path within the doir^in. The power up path set- 
up message performs this function by establishing rout- 
ing table entries, at the time the mobile device initially 
powers up, in the routers (including the base station to 
which the mobile device is attached). Only those routers 

IS which are utilized to route packets from the root router ' 
to the mobile device require routing table entries for the 
nrrabile device whrch is powering up. and therefore, only 
those routers are selected for fon^farding of the power 
up path setup message. 

20 [0037] The second type of path setup message is in- 
itiated and sent by a mobile device during mobile device 
handoft to another base station included within the do- 
main to which the mobile device is attached. This hand- 
off path setup message is used to update routing table 

2S entries for selected routers within the domain to reflect 
the mobile device handoff from one base station to an- 
other base station and ensure seamless packet delivery 
when such a handoff occurs. Only those domain routers 
having a routing table requiring updated routing table 

so entries as a result of the handoff are selected for receiv- 
ing the handoff path setup message. The handoff and 
power up path setup messages may be classified to- 
gether as update messages. 

[0038] The third type of path setup message, the re- 

35 fresh message, is initiated and sent by a base station 
(lor each mobile device anached through that base sta- 
tion) to the root router and intermediate routers to re- 
fresh soft-state routing table entries. The message may 
be sent individually for each mobile device, or in the al- 

40 ternative, the message may be an aggregation of re- 
fresh path setup messages for a plurality of mobile de- 
vices attached through the conveying base statnn. The 
refresh path setup message is used to refresh routing 
table entries for those selected routers within the do- 

4S rnain which are utilized tor packet transport from the root 
router to the base station initiating the message. 
[0039] A refresh path setup message Is utilized in con- 
junction with an embodiment of the present invention uti- 
lizing "soft-states' at routers. A soft -state router is a rout- 

so er which must receive a refresh path setup message pe- 
riodically within a specified period of time, othenvise the 
host based routing link is abandoned. A soft-state 
scheme Is particularly useful in HAWAII, where a mobile 
device user's mobility is accompanied by path setup 

ss messages establishing new host based routing entries 
responsive to each handoff. By periodically refreshing 
the host based routing entries, response to domain rout- 
ing changes (other than those necessitated by mobile 
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device handofls) are also accommodated. Non-handoff 
subnet changes may be initiated by a number of events, 
including but not limited to. faults due to broken links, 
node congestion, traffic control, etc. Refresh path setup 
messages therefore, unlike path setup messages Initi- 
aled tn response to pov/er up or handoff , are conveyed 
from base siaton to the domain root router for each mo- 
bile device attached to a domain base station. Thus, 
packet rerouting due to router or link failures while uti- 
lizing soft -slate routers in a HAWAII based domain is 
easity accomnrxxiated. Furthermore, elimination of one 
or more foreign agents in the packet path to a mobile 
device improves the reliability of data delivery to the mo- 
bile user 

[0040] Penodtc refresh messages associated with a 
routers sol I -slate routing table entries also altows for an 
aggregation of refresh messages corresponding to each 
individual mobile device attached at a base station, that 
is, the base station may send one refresh path setup 
message which coniains ihe Informaiksn Elements for 
each of the mobile users attached to its wireless inter- 
face. Furthermore, as is subsequently described, re- 
fresh path setup messages are sent to only a selected 
few routers within the domain, reducing the quantity of 
overhead associated with maintenance of router soft- 
states. 

[0041] The refresh path setup message does not re- 
quire an acknowledgment. Rather, toss of a refresh path 
setup message is tolerated by allowing the routing table 
entries for domain routers to expire only after several 
consecutive refresh path setup messages are not re- 
ceived. Update path setup messages (power up and re- 
fresh) are acknowledged and retransmitted if the mes- 
sage or acknowledgment is not received. Therefore, 
path setup schemes are robust and tolerant of path set- 
up message loss. 

[0042] FIGS. 7-9 are structural diagrams for the three 
types of path setup messages. Path setup messages 
include a six field Information Element 300. FIG. 7 is a 
structural diagram for the information Element fields of 
a refresh path setup message. FIG. 8 is a structural di- 
agram for the Information Element fields of a power up 
path setup message. FIG. 9 is a structural diagram for 
the Information Element fiekJs of a handoff path setup 
message. Some general obsen/aiions are first noted 
with regard to path setup messages prior to the descrip- 
tion of individual fields contained within the Information 
Element 300. First, as previously described, a refresh 
path setup message may be sent individually from a 
base station for each mobile device connected thereto, 
or in the alternative, one refresh path setup message 
including the Information Elements for a plurality of mo- 
bile devices connected to the base station may be con- 
veyed in aggregated form from the base station. Sec- 
ond.' an update path setup message refers to and in- 
cludes the remaining two types of setup messages: the 
power up path setup message and the handoff path set- 
up message. Third, an update path setup message in- 



cludes only one Information Element 300 corresponding 
to only one mobile device attachea to the base station. 
Fourth, each path setup message may optionally in- 
clude an authentication header to verify the authenticity 
5 of the message being conveyed. 

[0043] The Information Element 300 of a path setup 
message includes the following fields: {/) message type 
field 310. (//) sequence number fiekJ 31 2. {///) mobile de- 
vice IP address fiekJ 3i4. (/v) source IP address fiekJ 
10 316. (v) destination IP address field 318. and {vi) metric 
fiekJ 320. The message type field 310 is used to inform 
the receiving router which type of path setup message 
Is being received. The sequence number fiekJ 312 is 
used to prevent kxiping of packets between an old base 
IS station and a router when a mobile device is handed off. 
The mobile device IP address tieW 31 4 is used to infonn 
the receiving router of the current IP address assigned 
for the mobile device within the domain. The source IP 
address field 315 and the destination IP address field 
20 31 8 are used to provide the receiving router with specific 
IP addresses for the domain root router arKi base sta- 
tions (the specific information Included variable based 
upon the type of message it is included in). The metric 
fieki 320 identifies the number of hops from the base 
25 station or router processing the Infomiaton Elennent to 
the mobile device. Therefore, metric field 320 Is set to 
zero for path setup messages initiated by the mobile de- 
vice and set to one for refresh path setup messages in- 
itiated by the corresponding base station. Each base 
30 station or router processing the Information Element se- 
quentially increments the metric (certain path setup 
schemes, subsequently described, decrement the met- 
ric rather than Increment the metric). 
[0044] Referring only to FIG. 7, there is shown is a 
35 structural diagram for the Information Element fields of 
a refresh path setup message. The message type field 
310 indicates that the path setup message Is a refresh 
message. The function and use of the sequence number 
field 31 2 will be described in greaterdetail subsequently. 
■*o However, it is noted here that the sequence number field 
31 2 contained within a refresh message is set to the cur- 
rent sequence number field value stored at the base sta- 
tion initiating the refresh path setup message, but not 
less than one. The mobile device IP address field 314 
-ts Is set to the IP address assigned to the mobile device 
attached to the base station initiating the refresh path 
setup message. The source IP address fieki 3i6 is set 
to the IP address of the base station Initiating the refresh 
path setup message. The destinatton IP address field 
so 318 Is set to the IP address of the domain root router. 
The metric fieW 320 is set to one by the base station 
initiating the refresh path setup message and sequen- 
tially incremented by each successive router receiving 
the message. 

55 [0045] Referring only to FIG. 8. there is shown is a 
structural diagram for the Information Element fiekls of 
a power up path setup message. The message type field 
310 indicates that the path setup message is an update 
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messaga. The function and use of the sequence number 
field 31 2 will be described in greater detail subsequently. 
However, it is noted here that the sequence number field 
312 contained within a power up message is set to zero. 
The mobile device IP address field 314 is set to the mo- 
bile device's IP address. The source IP address field 
316 is set to the IP address of the current base station 
sen^icing the mobile device. The destination IP address 
field 31 6 is set to the IP address of the domain root rout- 
er. The metric field 320 is set to zero by the mobile de- 
vice initiating the power up path setup message and se- 
quentially incremented by each successive router re- 
ceiving the message. 

[0046] Referring only to FIG. 9, there is shown is a 
structural diagram for the Information Element fields of 
a handoff path setup message. The message type field 
310 indicates that the path setup message is an update 
message. The function and use of the sequence number 
field 312 will bedescrbed in greater detail subsequently. 
However, it is noted here that the sequence number field 
312 contained within a power up message is set to one 
more than the cun^ent stored sequence number field val- 
ue, but not less than two. The mobile device IP address 
field 314 is set to the mobile device's IP address. The 
source IP address field 316 is set to the IP address of 
the new base station to which the mobile device is hand- 
ed off. The destination IP address field 318 is set to the 
IP address of the old base station from which the mobile 
device is handed off. The metric field 320 is set to zero 
by the mobile device initiating the handoff path setup 
message and sequentially incremented by each suc- 
cessive router receiving the message. 

Power Up Path Setup Message 

[0047] FIG. 10 is a flow diagram for the method uti- 
lized by domain routers processing a power up path set- 
up message. When a mobile device initially powers up. 
it establishes a link with a nearby base station. During 
the period of 6nk establishment, or immediately there- 
after, the mobile device initiates a power up path setup 
message for conveyance to the domain root router, the 
connected base station, and each intermediate domain 
router which will be used for packet transport between 
the base station and the root router. The method illus- 
trated and described is applicable to each router (which, 
as previously described, encompasses domain base 
stations as well, since base stations maintain or access 
router capabilities to interface with the wired portion of 
the subnet) within a host based domain implementing 
HAWAII. In accordance with an exemplary embodiment 
of the present invention. The message processing pro- 
cedure described herein is performed utilizing process- 
ing and memory capacity available in current routers, as 
previously described. In accordance with step 340. a do- 
main router first receives a power up path setup mes- 
sage. The router increments the metric in step 342. In 
accordance with step 344. the router then identifies the 



router interface over which the instant path setup mes- 
sage was received and sets variable Intf 1 as that inter- 
face. A routing table entry is then entered, in accordance 
with step 346. which maps the mobile device's IP ad- 

5 dress to Intf 1 (the router interface identified in step 344). 
In step 348. the router queries whether the router ad- 
dress matches the address in the destinatbn IP address 
fieU of the instant path setup message, if yes. then the 
router is the domain root router and a path setup mes- 

10 sage acknowledgment is returned to the mobile device 
via the router/interface path just established, in accord- 
ance with step 352. If no. then the router kjentifies the 
next hop router to whk:h it will fonward the instant path 
setup message in order to reach the destination IP ad- 

15 dress of the instant message (the domain root router), 
in accordance with step 350. The router then waits lor 
a power up path setup message initiated from another 
mobile device, in accordance with step 354. When a 
new power up path setup message is received, the rout- 

20 er begins the message processing procedure again at 
step 340. 

[0048) FIG. 1 1 illusuates a power up path setup mes- 
sage processing sequence in an exemplary domain uti- 
lizing HAWAII host based architecture. It is noted that 
2S the use of 'Intf' indicates an interface or port over which 
one node is coupled with a second node. Domain root 
router 360 accesses the Internet 362 via domain root 
router Intf A. The domain root router 360 IntfB is coupled 
to router R7 Intf A. Domain root router 360 IntfC Is cou- 

30 pled to router RS IntfA. Router R7 IntfB Is coupled to 
base station BS9 IntfA. Router R7 IntIC Is coupled to 
base station BSIO IntfA. Router R8 IntfB is coupled to 
base station BSII IntfA. Router R8 IntfC is coupled to 
base station BS12 IntfA. 

3S [0049] A mobile device 114 is shown attempting a 
power up to establish a link with base station BS9 IntfB. 
Upon initiating the power up, the mobile device 114 is 
first assigned an IP address through the Dynamic Host 
Configuration Protocol (DHCP) sen/er (not shown). As- 

40 suming that the DHCP server is co-located at the root 
router, then base station BS9 will act as a DHCP sen/er 
relay, forwarding messages between the DHCP server 
and the mobile device. Upon successful authentication, 
the DHCP server assigns an IP address to the mobile 

•iS device 114 tor use within the domain and additionally 
conveys the IP addresses of base station BS9 and the 
domain root router 360 to the mobile device. The mobile 
device creates a power up path setup message with In- 
formation Element fields set as described in conjunction 

so with FIG. 3. The mobile device 114 then transmits the 
power up path setup message over a first hop 364 to 
base station BS9 IntfB. 

[OOSO] upon receiving the power up path setup mes- 
sage, base station 3S3 Increments the Information El- 
ss ement metric field and adds a routing entry for the mo- 
bile device 114 In its routing table. The entry for the mo- 
bile device is comprised of two ftekte. the mobile device 
IP address and an associated interface over which 
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packets received by BS9 for delivery to the mobile de- 
vice 114 are to be routed. The associated intertace is 
set to the same interface over which the instant power 
up path setup message was received (BS9 IntfB. the 
wireless interface in this case). BS9 next performs a 
routing table lookup to determine a gateway to which to 
forward the instant power up path setup message so as 
to complete transport to the address indicated in the 
destination IP address field. In a power up path setup 
message, the destination IP address field is set to the 
domain root router address. In the instant example. BS9 
determines that the appropriate gateway is router R7. 
Therefore, BS9 routes the instant power up path setup 
message for its second hop 366, from BS9 IntfA to R7 
IntfB. 

[0051] Upon receiving the power up path setup mes- 
sage, router R7 increments the Information Element 
metric field and adds a routing entry tor the mobile de- 
vice 11 4 in Its routing table in the same manner as base 
station BS9 did. Therefore, router R7 associates the mo- 
bile device IP address with the interlace over which the 
instant power up path setup message was received (R7 
IntfB). Router R7 then forwards the Instant power up 
path setup message to the domain root router 360 for 
the third hop 368, from R7 IntfA to IntfB of the dorr^ain 
root router 360. Upon receiving the power up path setup 
message, the domain root router 360 Increments the In- 
formation Element metric field and adds a routing entry 
for the mobile device 114 In its routing table in the same 
manner as previously described. Therefore, the domain 
root router 360 associates the mobile device IP address 
with the intertace over which the Instant power up path 
setup message was received (IntfB). The domain root 
router 360 then routes an acknowledgment 370 back to 
the mobile device 114 utilizing the routing table entries 
just established by the power up path setup message to 
correlate the mobile device's IP address with an inter- 
face at each router in the path. Subsequently, packets 
conveyed over the Internet for delivery to the mobile de- 
vice 1 1 4 are routed to the domain root router 360 based 
upon the subnet portion of the mobile device's IP ad- 
dress. Packets arriving at the domain root router 360 
having the mobile device's IP address are subsequently 
routed to the rrabite device 1 14 utilizing the host based 
routing entries created. Routers within the domain which 
have not received the power up path setup message, 
such as BS11. BS12 and R8. do not maintain routing 
entries corresponding to the mobile device's IP address. 
Therefore, these routers use a default routing path to 
the domain root router 360 for packets having a desti- 
nation address with no corresponding entry in the rout- 
ing table. Thus, a packet received at base station BSil 
having a destinaton address corresponding to the mo- 
bile device 114 is routed to the domain root router 360 
by default. Once received at the donrtain root router 360. 
the mobile device IP address is recognizable and an en- 
try in the resident routing table is available for transport 
of the packet to the mobile device 114. 



Refresh Path Setup Message 

[0052] FIG. 12 is a flow diagram for an exemplary 
method utilized by domain routers processing a refresh 
5 path setup message. As prevwusly described, the re- 
fresh message, is initialed and sent by a base siatwn 
(lor each mobile device attached through that base sta- 
tion) to the root router and intemiediate routers to re- 
fresh soft-state routing table entries. The message may 
fo be sent individually for each mobile device, or in the al- 
ternative, the message may be an aggregation of re- 
fresh path setup messages for a plurality of mobile de- 
vices attached through the conveying base station. The 
method herein illustrated and described is applk:able to 
IS each router (whch, as prevk>usly described, encom- 
passes domain base stations as well, since base sta- 
tions maintain or access router capabilities to interface 
with the wired portksn of the subnet) within a host based 
domain implementing HAWAII, in accordance with an 
20 exemplary embodiment of the present invenlkjn. The 
message processing procedure described herein is per- 
formed utilizing processing and memory capacity avail- 
able in current routers, as previously described. In ac- 
cordance with step 380, a domain router first receives 
2S a refresh up path setup message. The router increments 
the metric in step 382. In accordance with step 384, the 
router then Wentlfies the router interface over which the 
instant path setup message was received and sets var- 
iable Intf 1 as that interface. In accordance with step 383. 
30 the router checks whether there is an existing entry in 
the routing table for the mobile device IP address. If not. 
a routing table entry is then entered, in accordance with 
step 390, which maps the mobile device's IP address to 
Intf 1 (the router interface identified in step 384). If how- 
35 ever, there is an existing routing table entry for the mo- 
bile device IP address, then in accordance with step 
392, the sequence number of the instant refresh path 
setup message is compared to the existing router se- 
quence number entry. If the sequence number of the in- 
40 slant path setup message is greater than the existing 
router sequence number entry, it is indicative that the 
instant refresh path setup message contains more cur- 
rent Information Element fields than those fiekis current- 
ly available at the router, and in accordance with step 
45 394, Inlormation Element fields stored at the router are 
updated (refreshed) to reflect the more current values 
as transmitted in the instant refresh path setup mes- 
sage. 

[00S3] In step 396, the router queries whether the 
so router address matches the address in the destinatfon 
IP address field of the instant refresh path setup mes- 
sage. If the result of the query is negative, then the router 
klentifies the next hop router to which it will fooA^ard the 
instant refresh path setup message in order to reach the 
55 destination IP address of the instant message (the do- 
main root router), in accordance with step 398. If how- 
ever, the result of the query made in step 396 is affirm- 
ative, then the router is the domain root router and no 
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further forwarding of the instant refresh path setup mes- 
sage is required. 1! is also noted that an acknowtedg- 
meni of receipt by the domain root router is not required 
either. Then, in accordance with step 400. the router 
waits for the next refresh path setup message with which 
to update its routing table entries. Such a subsequent 
refresh path setup message may originate from the 
same base station or from another base station within 
the domain which utilizes the same router for forwarding 
packets to mobile devices which it services. Upon re- 
ceiving a new refresh path setup message, the process 
begins anew at step 380. 

[0054] Three path setup handoff schemes for use 
within the host based domain HAWAII architecture are 
subsequently described: a new-to-old path setup 
scheme, an old-to-new path setup scheme, and a new- 
tOK3ld-to-new path setup scheme. The power up and re- 
fresh path setup messages are used in conjunction with 
each Of the three handoff schemes presented herein. 
The three path setup handoff schemes differ in how the 
handoff path setup messages are coordinated, main- 
tained, and forwarded. The three path setup handoff 
schemes described herein do not assume any existing 
topological knowledge. That is. path setup messages 
are routed within the domain utilizing routing entries cre- 
ated by conventional routing protocols, such as Routing 
Information Protocol (RIP) or Open Shortest Path First 
(OSPF) and without using any additional information. 
However, it would be apparent to those skilled in the art 
to apply the path setup schemes described herein within 
a protocol responsive to domain node, link and router 
congestion and/or QoS guarantee commitments. 
[0OS5] The foltowing description, referring to FIGS. 
1 3-18. recites the details associated with the aforemen- 
tioned three path setup handoff schemes for use within 
the host based domain HAWAII architecture. They are: 
a new-to-oM path setup scheme, an old-to-new path set- 
up scheme, and a new-to-old-to-new path setup 
scheme. As the respective names imply, they represent 
three different means of conveying messages to apprise 
and update domain host routers of a molbiie device 
handoff event from an o\6 base station to a new base 
station. All three schemes limit the messaging and sig- 
naling required to Implement changes In the routing ta- 
ble entries of domain routers by updating only those se- 
lected routers for which the interlace used for packet de- 
livery has changed due to the mobile devk:e altering its 
attachment within the domain to a new base station. It 
should be noted that the order in which base stations 
are notified utilizing path setup schemes (i.e. - new-to- 
old, old-to-new. or new-to-old-to-new) refers to the order 
in which individual base stations and routers process the 
path setup messages at a logical level. The physical 
path over which the path setup messages are conveyed 
may be different than that described at the togical level. 
[0056] The term 'cross-over router* is subsequently 
used to describe path setup handoff schemes. Referring 
again to FIG. 2. the term cross-over router may be de- 



fined. Consider the elements which comprise Domain 1 
which include the domain root router 150. routers R4 
and R5. and base stations BSS. BS6. and 6S7. Assume 
that the mobile device 114 initially powers up while at- 

5 tached to base station BSS. The mobile device 1 1 4 ac- 
quires (or is permanently assigned) an IP address and 
initiates a power up path setup message to the domain 
root router 1 50 which adds routing table entries equating 
a router interface with its IP address in the domain root 

10 router and each intermediate router. Therefore, a packet 
received by the domain root router 150 having the mo- 
bile device's IP address will be routed over the appro- 
priate interface to router R4. Router R4 upon receiving 
the packet will route the packet over the appropriate in- 

is tertace to base station BSS. Base statbn 335 wilt trans- 
mit (he packet to the mobile device. Now assume that 
the mobile device 1 1 4 alters it point of attachment within 
(Domain 1 to base statbn BSS and that packets destined 
for the mobile device 1 1 4 are to be subsequently routed 

20 via the domain root router 1 50. through router R4 (albeit 
over a new interface), and base station BSS to the mo- 
bile device 114. It can be seen that the routing table en- 
tries for the mobile device's IP address stored at base 
stations BSS and BSS and at router R4 require updating, 

2S but that no change is required for the routing table entry 
at the domain root router 150. This is because the do- 
main root router forwards packets with the mobile de- 
vice's IP address to router R4 over the same interface 
regardless of whether ultimate delivery of the packet to 

30 the mobile device 114 is via base station BSS or BSo. 
The cross-over router in this case Is router R4. since it 
represents the first domain router in the packet delivery 
scheme whbh must alter the interface to which it for- 
wards a packet to the mobile device when the mobile 

3S device changes Its point of attachment from base station 
BSS to base station BSS. 

[0057] In each of the three path setup handoff 
schemes subsequently described, routing entries dur- 
ing a handoff from a first domain base station to a sec- 
40 ond domain base station are added to the existing rout- 
ing table so that packets received at the old base station 
prbr to completbn of the handoff, and prior to the com- 
pletion of routing table entry updates to donriain routers, 
will be delivered to the new base station for transmission 
45 to the mobile device. Updating routing entries in this 
manner prevents the possibility of loop (ormaiion result- 
ing in packet toss. Funhermore, all three path setup 
handoff schemes utilize the Information Element simc- 
ture shown in FIG. 9 and as described in the correspond- 
so ir)g description (with the exception that the source and 
destlnatbn IP address fields are interchanged when uti- 
lizing the oid-to-new path setup scheme, described sub- 
sequentty). However, the schemes differ in how domain 
routers interpret and respond to the Information Element 
ss field values. 
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New-toOld Path Setup Scheme 

[CX)58] FIG. 13 is a flow diagram for an exemplary 
method utilized by domain routers processing a new-to- 
old handoff path setup message. As previousty de- 
scribed, a handotf path setup message is initiated and 
sent by a mobile device from the new base station to the 
old base station and selected tntemiediate routers up to 
and including the cross-over router. The base statioris 
or routers which receive this message update their rout- 
ing table entries corresponding to the originating mobile 
device's IP address to point to the interface of the router 
or base station over which the handoff path setup mes- 
sage arrived. Spectficalty, domain routers receiving a 
handoff path setup message include (r) each router of 
the post-handofi packet delivery path between the new 
base station and the cross-over router fincluding the 
new base station and the cross-over router) and (/O each 
router of the pre-handoTf packet deSvery path between 
the cross-over router and the old base station (including 
the oki base station). The method illustrated and de- 
scribed is applicable to each router (which, as previously 
described, encompasses domain base stations as well, 
since base stations maintain or access router capabili- 
ties to interface with the wired portion of the subnet) 
within a host based domain implementing HAWAII, in 
accordance with an exemplary emtsodiment of the 
present invention. The message processing procedure 
described herein is performed utilizing processor and 
memory edacity available in current routers, as previ- 
ously described, tn accordance with step 410. a domain 
router first receives a handoff path setup message. The 
router increments the metric in step 41 2. In accordance 
with step 41 4, the router then klentifies the router inter- 
face over which the instant path setup message was re- 
ceived and sets variable Intfl as that interface. In ac- 
cordance with step 41 6, the router checks whether there 
is an existing entry in the routing table for the mobile 
devk:e IP address. If not. a routing table entry is then 
entered, in accordance with step 420. which maps the 
mobile device's IP address to Intfl (the router interface 
identified in step 414). If however, there is an existing 
routing table entry for the mobile device IP address, then 
in accordance with step 422, the sequence number of 
the instant handotf path setup message is compared to 
the existing router sequence number entry. If the se- 
quence number of the instant path setup message is 
greater than the existing router sequence number entry, 
it is indicative that the instant handoff path setup mes- 
sage contains more cun'ent Information Element fields 
than those stored at the router, and in accordance with 
step 424 the routing table entries for the mobile device 
are updated. 

[0059] In step 426. the router queries whether the 
router address matches the address in the destination 
address field of the instant handoff path setup message. 
If the result of the query is negative, then the router iden- 
tifies the next hop router to which it will forward the in- 



stant handoff path setup message in order to reach the 
destination IP address of the instant message (the oM 
base station), in accordance with step 428. If however, 
the result of the query made in step 426 is affirmative. 

5 then the router is the oU base station and no further for- 
warding of the instant handoff path setup message is 
required. An acknowledgment of receipt is launched to 
the new base station, in accordance with step 430. 
Whether or not the router receiving the handoff path set- 

10 up message is the old base station, the router waits for 
the next handoff path setup message, in accordarKe 
with step 432. Upon receiving a new handoff path setup 
message, the process begins anew at step 410. 
[0060] FIG. 14 illustrates a new-to-oM path setup 

IS scheme processing sequence in an exemplary donraain 
utilizing HAWAII host based architecture. It is noted that 
the use of 'Inif ' indicates an interface or port over which 
one node is coupled with a second node. Domain root 
router 360 accesses the Internet 362 via domain root 

20 router Intf A. The domain root router 360 Intf B is coupled 
to router R7 Intf A. Domain root router 360 IntfC is cou- 
pled to router RS Intf A. Router R7 IntfB is coupled to 
base station 889 IntfA. Router R7 IntfC is coupled to 
base station BSIO IntfA. Router R8 IntfB is coupled to 

2S base station 831 1 IntfA. Router R8 IntfC is coupled to 
base 8tatk>n 8312 IntfA. 

[0061 ] A mobile device 1 1 4 is shown during a handoff 
from old base station 839 to new base station BSIO. 
The mobile device 114 creates a handoff path setup 

30 message with Information Element fields set as de- 
scribed in conjunction with FIG. 9. The wcbWe device 
1 1 4 then transmits the handoff path setup message over 
a first hop 450 to base station BSIO IntfB. 
[0062] Upon receiving the handoff path setup mes- 

35 sage, base statbn BSlO increments the Information El- 
ement metric field and adds a routing entry for the mo- 
bile device 114 in its routing table. The entry for the mo- 
bile device is comprised of two fields, the mobile device 
IP address and an associated interface over which 

40 packets received by BSI 0 for delivery to the mobile de- 
vice 114 are to be routed. The associated interface is 
set to the same interface over which the instant handoff 
path setup message was received (BSi 0 IntfB, the wire- 
less interface in this case). BS 1 0 next performs a routing 

45 table lookup for the old base station's IP address (BS9 
IntfA address) to determine a fonwarding router to which 
next send the handoff path setup message so as to com- 
plete transport lo ihe address indicated in the destina- 
tion IP address field. In the instant example, BSIO de- 

so termines that the appropriate router to which to forward 
the handoff path setup message is router R7, which is 
the cross-over router. Therefore, BSIO routes the in- 
stant handoff path setup message for its second hop 
452. from BSlO IntfA to R7 IntfC. 

ss [0063] Upon receiving the handoff path setup mes- 
sage, router R7 increments the Infomnation Element 
metric field and updates the routing entry for the mobile 
device 114 in its routing table in the same manner as 
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base station BSlO did. Therelore. router R7 associates 
the mobile device's IP address with the interface over 
which the instant handoff path setup message was re- 
ceived (R7 InlfC). Router R7 then forwards ihe instant 
handoff path setup message to base station BS9 (the 
old base station) for the third hop 454. from R7 IntfB to 
BS9 IntfA. Upon receiving the handoff path setup mes- 
sage, base station BS9 increments the Information El- 
ement metric field and updates the routing entry for the 
mobile device 1 1 4 In its routing labte In the same manner 
as previously described. Therefore, base station BS9 
associates the mobile device IP address with the inter- 
face over which the instant handoff path setup message 
was received (IntfA). ThuS: packets subsequently proc- 
essed at base station BS9 which have the mobile de- 
vice's IP address In the packet's destination address 
field are redirected to base station BS1 0 for transmis- 
sion to the mobile device 114. Base station BS9 then 
routes an acknowledgment 456 back to the mobile de- 
vice 114 utilizing the routing table entries just estab- 
lished by the handoff path setup message to correlate 
the mobile device's IP address vrtth an interface at each 
router in the path. Subsequently, packets conveyed over 
the Internet 362 for delivery to the mobile device 114 are 
routed to the domain root router 360 based upon the 
subnet portion of the mobile device's IP address, which 
forwards the packets to router R7 Intf A (since the rout- 
ing table entry for the mobile device's IP address at the 
domain root router was nc^ altered by the handoff path 
setup message). Router R7 then routes packets having 
the mobile device's IP address to the mobile device 1 1 4 
from router R7 IntfC to base station BSIO IntfA as di- 
rected by its updated routing table entry for the mobile 
device's IP address. Base station BSlO routes packets 
having the mobile device's IP address to the mobile de- 
vice 114 over BSlO IntfB (BSIO's wireless Interface). 
Note that only the new and old base stations and the 
routers connecting them are involved In processing 
new-to-old handoff path setup messages. Other routers 
within the domain simply have a default entry pointing 
to the domain root router 360 and remain unchanged. 
[0054] As previously introduced, including a se- 
quence number field with the Informal on Element of a 
path setup message prevents looping of packets be- 
tween an old base station and a router when a mobile 
device is handed off. Although described within this sec- 
tion pertaining to the new-to-old path setup scheme, the 
utilization of sequence number fields prevents looping 
when applied to any path setup message or scheme de- 
scribed herein. Recall that the host based base stations 
of the present Invention periodically transmh a refresh 
setup message to the domain root router. Still re- 
ferring to FIG. 14, assume that a handoff path setup 
message has been created and launched from the mo- 
bile device, that the handoff path setup message has 
completed a second hop 452, and that router R7 has 
just completed processing the handoff path setup mes- 
sage. Also, assume that a periodic refresh path setup 



message has just been launched from base station BS9. 
Base station BS9 has not yet been notified of the mobile 
device 1 1 4 handoff to base station BSiO since it has not 
yet received the handoff path setup message. If the re- 
s fresh path setup message were to be processed at rout- 
er R7. Its routing table entry for the mobile device would 
be refreshed to indicate that the mobile devce is stilt 
attached at base station BS9 instead of its current point 
of attachment at base station BSlO. The handoff path 
10 setup message would be delivered to base station BS9 
after its third hop 454 and the routing table at BS9 would 
be updated to redirect packets destined for the mobile 
device 1 1 4 back to router R7. This scenario would result 
In packets having the mobile device I P address as a des- 
is tinalion address being looped back and forth between 
base station BS9 and router R7 until the next refresh 
path setup message is initiated. 
[0065] Packet kx>plng Is avoided, however, through 
the Inclusion of a sequence number field within path set- 
20 up messages. When a mobile device powers up, the val- 
ue of the sequence number field is set to zero, indicating 
that the nrrobile device has just powered up and has not 
been handed off to a neighboring base station. Each 
time the mobile device is handed off, the mobile device 
25 increments the sequence number sent with the Informa- 
tion Element. Therefore, a base station initiating a re- 
fresh path setup message would send an Information 
Element having a sequence number field set to the pre- 
handoff value (i.e. - the value corresponding to the se- 
30 quence number field value while still attached to that 
base station). The mobile device, having been handed 
off to a new base staibn. initiates a handoff path setup 
message having a sequence number field value incre- 
mented by one. Therefore, a refresh path setup mes- 
35 sage sent from base station BS9 and arriving at router 
R7 woukj have a sequence number field value less than 
the sequence number field value of the handoff path set- 
up message initiated by the mobile device 114. Router 
R7, realizing that the refresh path setup message is not 
40 as current as the handoff path setup message just re- 
ceived, simply forwards the refresh path setup message 
without altering the routing table entry corresponding to 
the mobile device. Thus, packet looping, and the unde- 
sirable effects it causes, are avoided. 
45 [0066] The sequence number field is set to zero dur- 
ing a power up to make sure that a power up path setup 
message is always processed. Doing so ensures packet 
delivery if the mobile device 114 resets itself (e.g. - as 
a result of a battery failure). Since a power up path setup 
so message has a sequence number field value equal to 
zero to indicate its status as a power up path setup mes- 
sage, refresh path setup messages have a sequence 
number field value set to a minimum value of one. Ad- 
ditionally, sequence number field values associated with 
55 handoff path setup messages generated by the mobBe 
device are incremented by one. in a wrap around man- 
ner, for each successive handoff. Therefore, handoff 
path setup messages have sequence number fiekJ val- 
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ues of between two and the maximum sequence 
number available (or the field. 
[0067] It is noted that utilization of a new-to^ld path 
setup scheme is especially well suited tor applications 
in which wireless devices concurrently tune to both the 
new and old base stations prior to and during mobile 
device handoff. such as a CDMA or wideband COMA 
network. When used in conjunction with a TDMA net- 
work, the new-to-oU path setup scheme may result in 
packet k>ss since the wireless link between the mobile 
device and the okJ base station may be torn down con- 
currently as the okl base station receives packets des- 
tined tor the mobile device. When used in conjunction 
with a CDMA or wideband CDMA network, the new-to- 
o\6 path setup scheme allows packets to be delivered 
to the mobile device from either the new or old base sta- 
tions. 

[0068] For example, assume that a handoff from base 
station BS9 to base station BS10 occurs. In a TDMA 
network, prior to BS10 picKing up the mobile device, 
BS9 will tear down its link with the mobile device. This 
is known as a hard handott. The illustrated handoff path 
setup messages 450.452,454,456 are shown in terms 
of logical sequence. However, assume that the path set- 
up message is initiated over a physical wireless link 
through BS9 prior to tearing down the established link 
with the mobile device 11 4. ThuS: once the routing table 
entries at BS10 and router R7 are updated, future pack- 
ets destined for the mobile device 114 will be directed 
to base station BSIO. Therefore, packets which were 
directed over interface R7 IntfB to BS9 prior to process- 
ing the path setup message may be dropped since the 
hard handoff to BS9 may occur in the interim. This is not 
the case with a CDMA network. Since the mobile device 
is able to tune and receive packets from two base sta- 
tions concurrently, the mobile device will receive the 
packets transmitted from BS9 and BSiO. 
[0069] FIG. 14 illustrates the new-to-oW path setup 
scheme processing sequence wherein cross-over rout- 
er R7 is interposed between the old base station (BS9) 
and the new base station (BSIO) over the wired portion 
of the subnet domain. However, what if base station 8S9 
and base station BSl 0 were wired directly to each other 
without an intermediate router interposed between? Af- 
ter processing a handoff path setup message In accord- 
ance with FIG. 14, packets destined for, the mobile de- 
vice 114 would be routed from the domain root router 
360 through router R7, through old base station BS9, 
forwarded from base station BS9 to the new base station 
(BSIO) and then to the mobile device. Assuming that 
the routing cost is based upon hop counts, routing pack- 
ets in this manner would result in a non-optinr^al routing 
path, since packets destined lor the mobile device from 
the domain root router 360 would be routed through the 
cross-over router R7 to base statnn BS9 and then to 
base station BSIO rather than directly to base station 
BSIO from router R7. 

[0070] FIG. 1 5 illustrates an embodiment of the new- 



to-okj path setup scheme processing sequence wherein 
the old base station is directly wired to the new base 
station, without the use of intermediate routers inter- 
posed between them. Therefore, in addition to the do- 

5 main interconnections previously described, base sta- 
tion BS9 IntfC is coupled to base station BSIO IntfC. As 
prevk)usiy described, a mobile device 11 4 is shown dur- 
ing a handoff from okJ base station BS9 to new base 
station BSlO. The mobile devk:e 1 1 4 creates a handoff 

TO path setup message with Infornnation Element fields set 
as described in conjunction with FIG. 9. The mobile de- 
vice 114 then transmits the handoff path setup message 
over the first hop 460 to base station BSIO IntfB. Base 
station BSl 0 adds or updates the routing table entry cor- 

is responding to the mobile device 114. increments the 
metric and then forwards the handoff path setup mes- 
sage over the second hop 462 from BSiO InttC to BS9 
IntfC. Base station BS9 updates the routing table entry 
corresponding to the mobile device 114, increments the 

20 metre, and returns an acknowledgment 464 back to the 
mobile device 114 utilizing the routing table enuies just 
established by the handoff path setup message in base 
stations BS9 and BSIO. 

[0071] The non-optimal routing path problem is cor- 
2S rected when new base station BSIO sends its next re- 
fresh path setup message. The refresh path setup mes- 
sage is sent in two hops to the domain root router. The 
first hop 466 Is to router R7 IntfC and the second hop 
468 is to the domain root router 360. Although there are 
30 no needed routing changes at the domain root router, 
the refresh path setup message is used to refresh the 
routing table entry for the mobile device at router R7. 
After processing the refresh path setup message, router 
R7 associates the mobile device's IP address with the 
35 intIC, the Interface over whch the refresh path setup 
message was received. Subsequently, all packets des- 
tined for the mobile device will be directed over router 
R7 IntfC to base station BSlO Intf A thus optimizing the 
routing path. 

^ [0072] Still referring to FIG. 15, consider a scenario 
v^rherein a link failure occurs for the link between base 
station BSIO and router R7. The next subsequent re- 
fresh path setup message launched from base station 
BSIO would be sent from base station BSl 0 IntC to base 

45 station BS9 InttC, from base station BS9 InifA to router 
R7 IntfB. and from router R7 InttA lo the domain root 
router 360. This new routing path would be used be- 
cause the subnet's routing protocol detects the link fail- 
ure and automatically selects the alternate route as a 

so gateway for the next best route from base station BSlO 
to the domain root router 360. As before, the refresh 
path setup message updates the routing table entry as- 
sociated with the mobile device at each subsequent 
router receiving the message to establish the new path 
■ ss for packet delivery to the mobile device 114. 

[0073] An interesting embodiment of the present in- 
vention is a variatbn of the new-lo-old path setup 
scheme and is referrec to as an 'old-to-new' path setup 
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scheme. The old-to-new path setup scheme is similar 
to the new-to-otd path setup scheme with two major ex- 
ceptions. First, a handoff path setup message is sent by 
the mobile device to the old base station rather than to 
the new base station. The old base station then routes 
the handoff path setup message back to the mobile de- 
vice through the new base station and intermediate rout- 
ers, updating the routing table entries corresponding to 
the mobile device at each router or base station. Sec- 
ond, the metric field is initially established at the old base 
station as one more than the metric field value associ- 
ated with its routing table entry corresponding to the new 
base station and then decremented for each hop ol the 
handoff path setup message back to the mobile device. 

New-to-Old-to-New Path Setup Scheme 

[0074] FIGS. 16a and I6b are flow diagrams for an 
exemplary method utilized by domain routers process- 
ing a new-io-otdHo-new handoff path setup message. 
As prevbusly described, a handoff path setup message 
is initiated and sent by a mobile device to update the 
routing table entries for domain routers to reflect the mo- 
bile dev'ce's new point of attachment at a new base sta- 
tion. The new-to-oU-to-new handoff path setup mes- 
sage first forwards the path setup message from the 
new base station to the old base station (in phase 1 of 
the path setup message which is illustrated in FIG. 16a) 
and then forwards the path setup message from the old 
base station to the new base station (in phase 2 of the 
path setup message which is illustrated in FIG. 16b). 
The method illustrated and described is applicable to 
each router (which, as previously described, encom- 
passes domari base stations as well, since base sta- 
tions maintain or access router capabilities to interface 
with the wired portion of the subnet) within a host based 
domain implementing HAWAII, in accordance with an 
exemplaiy embodiment of the present invention. The 
message processing procedure described herein is per- 
formed utilizing processor and memory capacity availa- 
ble in current routers, as previously described. 
[0075] The new-to-okj-to-new handoff path setup 
scheme is more complex than either the previously de- 
scribed new-to-okj path setup scheme or the oM-to-new 
path setup scheme. The new-to-old-to-new harrdoff 
path setup scheme utilizes a modified routing table 
structure. Standard routing table entries utilize two fields 
to determine subsequent routing paths (as previously 
described), associating an IP address with a router in- 
terface over which packets having that IP address as a 
destination address will be fonfvarded. The routing table 
structure is modified when implementing a new-to-okj- 
to-new handoff path setup scheme to include three 
fields. The router interface over whk:h an I? packet is to 
be fonuarded is determined as a function of the router 
interface over which the packet was received in addition 
to the destination IP address. Therefore, it is possible 
to route a packet having the same destination IP ad- 



dress over different interfaces, depending upon over 
which router incoming interface the packet was re- 
ceived. The enhanced routing table entries are of the 
form ([Intf in.lP address] Intf out). However, it is noted 

s that the format of the forwarding tables on the interface 
pons for the router may remain the same. 
[0076] Referring now to FIG. 1 6a. and in accordance 
with step 480, a domain router first receives a new-to- 
old-to-new phase 1 handoff path setup message. Status 

'0 as a phase 1 message indN:ates that the message is 
being processed at a router in the path from the mobile 
device to the oUS base station (Le. - the new-to-oW leg 
of the message path). The router increments the metric 
in step 482. In accordance with step 464. the router then 

IS identifies the router interface over which the instant path 
setup message was received and sets variable Intf 1 to 
correspond to that interface. In accordance with step 
466. the router checks whether its address is the same 
as the destination address in the instant path setup mes- 

20 sage. If the router is the destination address (indicating 
that the router is actually the okJ base station), then step 
488 is performed. 

[0077] In accordance with step 488, when a phase 1 
handoff path setup message is received by the old base 

2S station, a routing table entry is created of the form ([«, 
MD address] -> intf 1 ). This notation indicates that pack- 
ets arriving at the router (the old base station for the in- 
stant example) will be routed over the outgoing interface 
identified in step 484 (Intfl). regardless of the incoming 

30 interface over which it was received. In accordance with 
step 490. the next hop router attached to Intfl is identi- 
fied, the destinaVion IP address for a phase 2 path setup 
message is set to that of the mobile device, and the 
phase 2 path setup message is launched. The router 

3S then waits, in accordance with step 504, for the next re- 
ceived phase 1 path setup message. 
[0078] However, if the result of the check performed 
in accordance with step 486 indk:ates that the router re- 
ceiving the instant message is not the router indicated 

40 in the destination IP address field of the path setup mes- 
sage, then step 492 is performed. In accordance with 
step 492. the router identifies the router interface over 
which the instant path setup message is to be fooA/arded 
and denotes this interface as variable Intf 2. This deter- 

4S minaibn is based upon the destination address field of 
the instant path setup message, which is me IP address 
of the okj base statk^n. In step 494, the router queries 
whether a routing table entry exists for the mobile de- 
vtee's IP address. If there is no routing table entry ccr- 

so responding to the mobile device's IP address, then in 
accordance with step ^96, an routing table entry for the 
mobile device's IP address te made. The entry is of the 
form ((*,MD address] Intfl ). indicating that a packet 
arriving at the router having a destination IP address 

55 corresponding to that cf the mobile devrce will be routed 
over intfl, regardless of the interface over whrch it was 
received. The path setup message is then forwarded to 
the next hop router using Intf2. in accordance with step 
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502. 

[0079] Returning to step 494. if it is determined that a 
routing table entry corresponding to the mobile device's 
IP address does exist, then step 498 is performed. In 
step 498. the sequence number of the instant handoff 
path setup message is compared to the existing router 
sequence number entry. If the sequence number ol the 
instant path setup message less than or equal to the 
existing router sequence number entry, it is indicative 
that the instant handoff path setup message is less cur- 
rent than the Information Element Held values stored at 
the router, and the instant path setup message is not 
processed further at the instant router. Rather, step 502 
is performed, in which the instant path setup message 
is forwarded to the next hop router using Intf 2. 
[0080] If however, the sequence number of the instant 
path setup message is greater than the existing router 
sequence number entry, it is indicative that the instant 
handoff path setup message contains more current In- 
formation Element fields than those stored at the router, 
and step 500 is performed. A routing table entry is added 
of the;fcrm ([Intf2,MD address] Intf1). It is important 
to note that this entry is added, as opposed to replacing 
the existing entry. The existing entry Is updated to be of 
the form ([-lntf2.MD address] -> IntfX). These two en- 
tries now exist concurrently in the routing table and have 
the following effect. A packet received at the instant rout- 
er over Intf 2 and having the mobile device's IP address 
as the destination address will be fonArarded over Intf 1 . 
whereas a packet having the mobile devk:e's IP address 
as the destination address and received at the instant 
router over any interface other than Intf 2 will be forward- 
ed over Intf X (the interface associated with the entry de- 
termined to exist in step 494). In accordance with step 
502, the instant path setup message is forwarded to the 
next hop router using Intf2. The router then waits, in ac- 
cordance with step 504. for the next received phase 1 
path setup message. 

[0081] Referring now to FIG. 16b. and in acccrdance 
with step 520, a domain router first receives a new-to- 
old-to-new phase 2 handoff path setup message. Status 
as a phase 2 message indicates that the message is 
being processed at a router in the path Irom the old base 
station back to the mobile device (i.e. - the old-to-new 
leg of the message path). The router decrements the 
metric, since the message is one hop closer to the mo- 
bile device with each subsequent phase 2 hop. in ac- 
cordance with 522. In step 524. the router then identifies 
the router interface over which the instant path setup 
message was received and sets variable Intf 1 to corre- 
spond to that interface. In step 526. the router queries 
whether a routing table entry exists of the form 
{[Intfl.MD address] -)> IntfX), meaning the router proc- 
essor checks whether there is an routing table entry 
which would forward received packets over a specified 
interface (IntfX) if the packets are received over Intfl 
and have the mobile device's IP address as the desti- 
nation address. If no such entry exists, then in accord- 



ance with step 532. forward the path setup message on 
a next hop as determined solely by the destination IP 
address included within the path.setup message, and 
regardless of the interface over which the path setup 
5 message was received. However, if the query 
performed ;in accordance with step 526 indicates that 
an entry of the form ((Intfl.MD address] IntfX) does 
exist, then perform step 528. 

[0082] In step 528, the sequence number of the in- 
10 stant handoff path setup message is compared to the 
existing router sequence number entry. If the sequence 
number of the instant path setup message less than or 
equal to the existing router sequence number entry, it is 
indicative that the instant handoff path setup message 
IS is less current than the Information Element field values 
stored at the instant router, and the instant path setup 
message is not processed further at the instant router 
Rather, step 532 is performed, in which the instant path 
setup message is fonwarded to the next hop router via 
20 IntfX 

[0083] If however, the sequence number of the instant 
path setup message is greater than the existing router 
sequence number entry, it is indicative that the instant 
handoff path setup message contains more current In- 
25 formation Element fields than those stored at the router, 
and step 530 is performed. The routing table entry at the 
instant router is updated so that all entries having the 
mobile device's IP address for the destination address 
field are modified to the form ([*,MD address] InifX). 
30 That is. an entry having the mobile device's IP address 
is modified so that regardless of the interface over which 
subsequent packets are received, the packets are for- 
warded to the interface which existed in the entry prior 
to the instant modification (IntfX). In accordance with 
3S step 532. the instant path setup message is forvyrarded 
to the next hep router via IntfX. Regardless of the steps 
taken to arrive at and accomplish step 532. the router 
then waits until a next new-toold-to-new phase 2 hand- 
off path setup message is received. Once received, the 
40 process begins anew at step 520. 

[0084] FIG. 17 illustrates a new-to-old-to-new path 
setup scheme processing sequence in an exemplary 
domain utilizing HAWAII host based architecture. It is 
noted that the use of "Intf" indicates an interface or port 
45 over which one node is coupled with a second node. 
Domain root router 360 accesses the Internet 362 via 
domain root router Intf A. The domain root router 360 In- 
tfB is coupled to router R7 InUA. Domain root router 360 
IntfC is coupled to router RB Intf A. Router R7 IntfB is 
50 coupled to base staticn BS9 Intf A Router R7 InifC is 
coupled to base station BSiO Intf A. Router R8 IntfB is 
coupled to base station BS11 Intf A. Router RS IntfC is 
coupled to base station BSl 2 Intf A. 
[0085] A mobile device n 4 is shown during a handoff 
55 from old base station BS9 to new base station BSll. 
The nrwDbile device 114 creates a new-to-okj-to-new 
phase 1 handoff path setup message with Information 
Element fields set as described in conjunction with FIG. 
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9. The mobile device 1 1 4 then transmits the handoff path 
setup message over a first hop 550 to base station BSil 
IntfB. 

[0086] Upon receiving the instant handoff path setup 
message, base station BS11 increments the Information 
Elcmcn! metric field and creates a routing table entry 
coircsponctng to the IP address of the mobile device 
114 The entry lor the mobile device, as previously de- 
scribed IS an enhanced entry comprised of three fields, 
the incoming interface and the nrx>bile device IP address 
determining the associated outgoing interface ever 
whch packets received by base station BSlI for deliv- 
ery 10 the mobile device 114 are to be routed. Prior to 
receiving Hnd processing the instant path setup mes- 
sage base siaion B5 1 1 maintains a default entry as ([*. 
Dela -jti) — 6S 11 tntl A). After processing the instant path 
setup message, base station BS11 creates an entry of 
the form (|*.M0 address] ^ BSi 1 1ntfB). That is, the as- 
sociated outgoing interlace is set to the same interface 
over whch the instant handoff path setup message was 
received (BSlI IntfB. the wireless interface in this case). 
BS11 next performs a routing table lockup for the old 
base station's IP address (BS3 address) to determine a 
forwarding router to which next send the handoff path 
setup message so as to complete transport to the ad- 
dress indicated in the destination I P address field. In the 
instant example, BS11 determines that the appropriate 
router to which to forward the handoff path setup mes- 
sage is router R8. Therefore. BSlI routes the instant 
handoff path setup message for its second hop 552. 
from BSil IntfA to R8 IntfB. 

[0087] Upon receiving the instant handoff path setup 
message, router R8 increments the Information Ele- 
ment metric field and creates a routing table entry cor- 
responding to the mobile device 114. Prior to receiving 
and processing the instant path setup message, router 
R8 maintained a default entry as ([«. Default] R8 Int- 
fA). After processing the instant path setup message, 
router RB creates an entry of the form ([*.MD address] 
R8 IntfB). That is, for a packet having the mobile de- 
vice's packet address as the IP header destination ad- 
dress, the associated outgoing interface used is the 
same interface over which the instant handoff path set- 
up message was received (R3 inttB), regardless of the 
incoming interface over which the packet is received. 
Router R8 next performs a routing table lookup for the 
old base station's IP address (8S9 address) to deter- 
mine a forwarding router to which next send the handoff 
path setup message so as to complete transport to the 
address indicated in the destination IP address field. In 
the instant example, router R3 determines that the ap- 
propriate router to which to fonward the handoff path set- 
up message is the domain root router (DRR) 360. There- 
fore, router R3 forwards the instant handoff path setup 
message for its third hop 554. from router R8 IntfA to 
the domain root router IntfC. 

[0088] Upon receiving the instant handoff path setup 
message, the domain root router 360 increments the In- 
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formation Element metric field artd adds a routing table 
entry corresponding to the mobile device 114. Prior to 
receiving and processing the instant path setup mes- 
sage, the domain root router 360 maintained a routing 

s table entry for delivery of packets destined for the mobile 
devce via base station BS9 as ([*.M0 address) DRR 
IntfB). which was established by an earfier path setup 
message. This entry specified that regardless of the in- 
coming interface over which a packet was received, if 

10 the packet included the mobile device's IP address as 
the IP header destination address, it was fonwarded 
from the domain root router 360 via DRR IntfB. After 
processing the instant path setup message, the domain 
root router 360 modifies the existing routing table entry 

15 to be of the form ((-DRR IntfB. MD address] DRR In- 
tfB) and adds an additional entry of the form ([DRR InttB, 
MD address) DRR IntfC). Therefore, a packet having 
the mobile device as the destination IP address which 
is subsequently received at the domain root router 360 

20 is forwarded via one of two interfaces, depending upon 
the interface over which the packet is received. If the 
packet is subsequently received over incoming interface 
DRR IntfB, the packet is forwarded via DRR IntfC to rout- 
er R8 and eventually to the mobile device attached via 

2S base station BS11. If, however, the packet is subse- 
quently received over any incoming interface other than 
DRR IntfB. then the packet is forwarded via DRR IntfB. 
After processing, the instant handoff path setup mes- 
sage is fonwarded for its fourth hop 556, from the DRR 

30 IntfB to router R7 IntfA. 

[0089] Upon receiving the instant handoff path setup 
message, router R7 increments the Information Ele- 
ment metric field and updates the routing table entry cor- 
responding to the IP address of the mobile device 114. 

35 Prior to receiving and processing the instant path setup 
message. rcLler R7 maintained a routing table entry for 
delivery of packets destined for the mobile device via 
base station BS9 as ([*,MD address] R7 IntfB), which 
specified that regardless of the incoming interface over 

40 which a packet was received, if the packet included the 
mobile device's IP address as the IP header destination 
address, it was forwarded from router R7 to base statran 
BS9 via R7 InttB. After processing the instant path setup 
message, router R7 modifies the existing routing table 

45 entry to be of the form ((-R7 IntfB, MD address] ^ R7 
IntfB) and adds an additional entry of the form ((R7 IntfB, 
MD address] R7 IntfA). Therefore, a packet having 
the mobile devrce as the destination IP address which 
is subsequently received at router R7. is forwarded via 

50 one of two interfaces, depending upon the interface over 
which the packet is received. If the packet is subse- 
quently received over incoming interface R7 InttB, the 
packet is fon^farded via R7 IntfA to the domain root rout- 
er 360 and eventually to the mobile device attached via 
55 base station BSli. If. however, the packet is subse- 
quently received over any incoming interface other than 
R7 IntfB. then the packet is forwarded via R7 IntfB. After 
processing, the instant handoff path setup message is 
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fonwarded for its fifth hop 558. from router R7 IntfB to 
base station BS9 Intf A. 

[0090] Upon receiving the instant handoff path setup 
message, base station BS3 increments the Infomnation 
Element metric field and updates the routing table entry 
corresponding to the IP address of the mobile device 
114. Prior to receiving and processing the instant path 
setup message, the old base station (BS9) n^intained 
a routing table entiy for delivery of packets destined for 
the mobile device as ([*.MD address) BS9 IntfB), 
which specified that regardless of the incoming iriterface 
over which a packet was received, if the packet included 
the mobile device's IP address as the tP header desti- 
nation address, it was forwarded from base station BS9 
to the mobile device via outgoing interface BS9 IntfB. 
After processing the instant path setup message, base 
station BS9 updates the routing table entry correspond- 
ing to the mobile device's address to be of the form ([*, 
MD address] BS9 Intf A). Therefore, any packet hav- 
ing the mobile device address (or the packet header 
destination IP address and which is subsequently re- 
ceived at base statbn 3S9 is forwarded from the old 
base station via BS9 intf A, regardless of the interlace 
over which the packet was received (thus redirecting 
packets over the wired portion of the domain for delivery 
to base station BS1 1 and transmission over the wireless 
interface at BS11 to the mobile device). Processing of 
the phase 1 portion of the new-to-old-to-new handoff 
path setup scheme is completed by altering the desti- 
nation address Information Element field of the path set- 
up message to correspond to the IP address of the mo- 
bile device. The altered message is now considered a 
new-to-old-to-new phase 2 handoff path setup mes- 
sage. The new-to-old-to-new phase 2 handoff path set- 
up message is forwarded via a sixth hop £60, from BS9 
IntfA to router R7 IntfB. 

[0091] Upon receiving the instant new-to-old-to-new 
phase 2 handoff path setup message, router R7 decre- 
ments the Information Element metric field and updates 
the routing table entries corresponding to the IP address 
of the mobile device 1 1 4. Prior to receiving and process- 
ing the instant path setup message, two routing table 
entries tor delivery of packets destined for the mobile 
device were created and nriaintained: a first entry ol the 
form ({-R7 IntfB, MD address] R7 IntfB) and a second 
entry of the torm ([R7 InifB.MD address] -4 R7 IntfA). 
After processing the Instant path setup message, router 
R7 replaces the two existing entries corresponding to 
the mobile device's IP address with one entry of the form 
((*.MD address] R7 IntfA). Therefore, router R7 sub- 
sequently forwards all packets having the mobile de- 
vice's address as the IP header destination address via 
outgoing interface R7 IntfA. regardless of the interface 
over which the packets are received. After processing, 
the instant handoff path setup message is forwarded 
over its seventh hop 562. from router R7 IntfA to the do- 
main root router 360. 

[0092] Upon receiving the instant new-to-oid-to-new 



phase 2 handoff path setup message, the domain root 
router 360 decrements the Information Element metric 
fiekj and updates the routing table entries correspond- 
ing to the IP address of the mobile device 114. Prior to 

s receiving and processing the instant path setup mes- 
sage, two routing table entries for delivery of packets 
destined for the mobile device were created and main- 
tained: a first entry of the form ({-DRR lntfB.MD ad- 
dress] R7 IntfB) and a second entry of the fonr^ ([ORR 

10 IntfB. MD address] R7 IntIC). After processing the In- 
stant path setup message, the domain root router 360 
replaces the two existing entries corresponding to the 
mobile device's IP address with one entry of the form 
((•.MD address] ORR IntfC). Therefore, the domain 

IS root router 360 subsequently forwards all packets hav- 
ing the mobile device's address as the IP header desti- 
nation address via outgoing interlace ORR IntfC, re- 
gardless of the incoming interlace over which the pack- 
ets are received. After processing, the instant handoff 

zo path setup message is forwarded over its eighth hop 
564, from the domain root router 360 interface DRR In- 
tfC to router R8 at incoming interface R8 IntfA. 
[0093] Upon receiving the instant new-to-old-to-new 
handoff path setup message, router R8 decrements the 

2$ Information Element metric field. The routing table entry 
associated with the mobile device requires no updating 
since it is singular (the outgoing interlace utilized for 
packet forwarding depends only upon the destination 
address of the IP header and is not dependent upon the 

30 incoming interface over which the packet is received) 
and correctly reflects the interface over which packets 
subsequently received, and destined for the mobile de- 
vice, are to be routed. The instant handoff path setup 
message is next forwarded over its ninth hop 566, from 

35 router R8 IntfB to base station BSil IntfA. 

[0094] Upon receiving the instant new-to-old -to- new 
handoff path setup message, the new base station 
(BS11) decrements the Information Element metric 
field. The routing table entry associated with the mobile 

40 device requires no updating since it is singular (the out- 
going interface utilized for packet forwarding depends 
only upon the destination address of the IP header and 
is not dependent upon the Incoming interface over which 
the packet is received) and correctly reflects the inter- 
ns face over which packets subsequently received, and 
destined for the mobile device, are to be routed. The 
instant handoff path setup message is next fonwarded 
over its tenth hop 568, from base station BS 11 IntfB to 
the mobile device. Receipt of the return handoff path 

so setup message acts as an acknowledgment that the do- 
main wired routing update procedure has been complet- 
ed satisfactorily. 

[0095] It is noted that utilization of a new-to-old-to- 
new handoff path setup scheme is especially well suited 
SS for applications wherein wireless devices tune to only 
one base station at a time, such as is done when utilizing 
TDfy/lA equipment. Within a TDMA network, there is no 
concept of a soft handoff (since the mobile device does 
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not tune to the old and new base stations concurrently). 
Rather, a TOMA mobile device tunes to the old bass sta- 
tion and as it approaches a new base station it simulta- 
neously estabBshes a new link with the new base station 
as it tears down the old link with the oU base statkx). 
With the new-to-otd scheme, packets may be fonwaided 
to the oU base statbn during the same time period in 
which the old link is being torn down and prior to the 
establishment of the new link. Therefore, use of a new- 
to-oU scheme or an old-to-new scheme may result in 
packet k»s. However, the new-to-okj-to-new handoff 
path setup scheme ensures that packets fonwarded to 
the okj base station at the same time an ok) link is being 
torn down will be forwarded to the new base statton. 
Therefore the risk of packet toss during handoff is min- 
imized. 

[0096] FIG. 18 is an illustration of an exemplary em- 
bodiment of a router 580 having a routing table 590 im- 
plemented in memory 588. Routers are comprised of a 
plurality of ingress ports (or interlaces) 562 for receiving 
packets from a previous node and a plurality of egress 
ports (or interfaces) 584 for sending packets to a next 
hop. It is known to those skilled in the art that interfaces 
may be bi-directional as well. That is, an interface may 
act as both an ingress and egress interface. Additionally, 
a router 580 includes a processor 5S6 and memory 538. 
The processing and memory resources resident at a 
router enable the provisioning of router functions and 
services such as: implementing forwarding algorithms, 
queuing, signaling, messaging, implementing a routing 
table 590. as well as other standard and supplemental 
router f uncttons and services. The router 580 illustrated 
in FIG. 18 shows a routing table 590 implemented uti- 
lizing the resources'of the router memory 588. A routing 
table 590 is comprised of a plurality of routing entries 
which are stored in a partitioned portion of the router 
memory 588 assigned for storage of element fields as- 
sociated with the routing table 590. The router processor 
586 is utilized to initially determine; routing entry values 
and to interface with the router memory 538 (or storing, 
updating, and accessing those values. 
[0097] The aforementioned path setup schemes v;ere 
implemented by modifying and extending version 2 of 
the Pouting Information Protocol (RlPv2). The following 
is a description of an exemplary method utilized to mod- 
el a new-to-old path setup scheme using RlPv2. The im- 
plementation of other path setup schemes is performed 
in a similar manner. The processing at a node proceeds 
as follows. A typical RIPv2 update message includes a 
family field identifier of AFJNET. One embodiment of 
the present inventton utilizes HAWAII path setup mes- 
sages having a family identifier of AF_MOBlNET to dis- 
tinguish it from routing update messages. Among the 
various path setup messages, refresh path setup mes- 
sages are implemented utilizing a command field of 
RIPCMD.RESPONSE. while update path setup mes- 
sages are implemented utilizing a conrunand field of 
RIPCMD_RESPONSE.ACK. 



[0098] When a routing daennon receives a RIP mes- 
sage having a family identifier of AF.MOBINET. it incre- 
ments the metric field and adds an entry of the form: (IP 
Address of MobAe Device ^ Interface on which mes- 

5 sage received). If the routing daemon already possess- 
es an entry coaesponding to the mobile device, the ex- 
isting entry is updated if a sequence number associated 
with the message is either zero or greater than the se- 
quence number of the existing entry corresponding to 

10 the mobile device. The routing daemon then determines 
the interface on whk;h the message is to be forwarded. 
This is performed by utilizing the routing table entry cor- 
responding to the destination address field in the mes- 
sage. The message is then forwarded to a next hop rout- 

is er. If the address associated with the next hop router is 
the same as one of the interface addresses of the cur- 
rent router or base statkin, then the path setup message 
has reached its final destinatk^ address. When the 
message reaches its final destination address, an ac- 

20 knowledgmenl is generated when the command field is 
set as RIP^RESPONSE^ACK, as is the case for update 
path setup messages. The generated acknowledgment 
is then forwarded to the mobile device. If aulhenticatton 
infornnatton is maintained at domain base stations, then 

25 an acknowledgment containing the authentication infor- 
mation is first sent to the new base station which then 
forwards the acknowledgment to the mobile device. 
[0099] Integratton of the Routing Information Protocol 
(RIP) and the Mobile IP standards within a Dynamic 

30 Host Configuration Protocol (DHCP) server is accom- 
plished in accordance with the following exemplary de- 
scription. When a mobile device Is powered up, it first 
sends a DHCP.DISCOVER message to the base sta- 
tion to which it attaches upon power up. The base station 

35 therefore serves as a DHCP relay and forwards the 
DHCP_DISCOVER message to the DHCP ser/er. The 
DHCP sen/er conveys a reply to the mobile device with 
a 0HCP_OFFER message. The mobile device then 
conviBys a DHCP^REQUEST message to the base sta- 

40 tlon which relays the message to the DHCP server. The 
DHCP server then sends a DHCP_RESPONSE, which 
contains the mobile device's assigned address (the 'ci- 
addr* field), the base station's address (the 'giaddr' 
field) . and the domain root router's address (the 'siaddr* 

•*5 field). The mobile device then sends an update path set- 
up message to the current base station with a sequence 
number of zero and with the final destination as the do- 
main root router. This message establishes routing en- 
tries in selected routers within the domain so that pack- 

50 ets arriving at the domain root router are delix'ered to the 
mobile device. When the mobile device is handed off to 
a new base station within the same domain, it updates 
its sequence number as previously described and sends 
a path setup message using the new-to-old path setup 

5S scheme to maintain connectivity after handoff. It the mo- 
bile device is handed off to a new base statton within a 
new dorrain. the mobile device acquires a care-ol ad- 
dress via the DHCP sen/er ol the new domain. The mo- 
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bile device then informs the home agent in the previous 
domain as to its new care-of address. Packets are then 
tunneled between the home agent and the new care-of 
address for as long as the mobile device is still attached 
to a base station within the new domain. When the mo- 
bile GGvce IS powered down, the address assigned from 
the CHCP sender in the new domain and/or the address 
assigned from the OHCP sender in the original domain 
are relinquished for reuse. 

[0100] Authentication infomiation may be utilized to 
disallow arbitrary users from sending path setup mes- 
sages and thereby subverting another user's packet 
transmissions. The path setup messages considered 
withm ihc embodiment of HAWAII described herein are 
deenrtcd secure because they each require cooperation 
and parlicipaiion by the old base station in order to Im- 
plement the handotf path setup scheme. Authentication 
inlormation tor the user is first stored in the current base 
station when the mobile device powers up. When the 
mobile device is handed off to a new base station, the 
old base station approves the path setup message only 
if the mobile device is able to authenticate itself in the 
path setup message. The authentication information is 
then transferred from the user's okj base station to the 
new base stalion on the acknowledgment of the path 
setup message. The assignment of an IP address dur- 
ing mobile device power up registration also needs to 
be secured to prevent arbitrary users from acquiring the 
IP address. This is achieved either using a mechanism 
such as Home Location Register (HLR) authentication, 
as is currently performed In cellular networks, or using 
the RADIUS protocol authentkration mechanism. 

TUNNELING OPTIMIZATION 

[0101] FIG. 1 9 is a diagram illustrating the Mobile IP 
standard method utilized for tunneling IP packets from 
a mobile device's home agent to the mobile device's for- 
eign agent Packets launched from a correspondent 
node 600 for delivery to a mobile devrce 608 are first 
routed to a node hosting the home agent 602 of the mo- 
bile device 608. The home agent 602 is a registered 
agent for the mobile devk:e 603 to which all packets hav- 
ing the mobile device's IP address as a destination ad- 
dress are first routed. The path between the correspond- 
ent node 600 and the home agent 602 is not shown In 
its entirety. The Internet, private intranets, and/or a plu- 
rality of routers and nodes may be inlerposed between 
the correspondent node 600 and the home agent 602. 
The home agent 602. upon receiving a packet having 
the mobile device's IP address as a destination address 
forwards the packet to the mobile device's foreign agent 
610. which in the instant embodiment is shown co-locat- 
ed at the mobile device 608. The mobile device 610 is 
shown maintaining an established a wireless connec- 
tion with a base station 606. A router 604 is shown in- 
terposed between the base statksn 606 and the home 
agent 602. The tunneling path between the home agent 



602 and the mobile device 610 is not shown in its en- 
tirety. The Internet, private intranets, and/or a plurality 
of routers and nodes may be interposed between the 
home agent 602 and the mobile device 608. 
5 [0102] An IP packet 6i2 conveyed from the corre- 
spondent node 600 for delivery to the mobile device 608 
is first received at a node hosting the home agent 602. 
The IP packet 612 is typically limited in size, 1500 bytes 
in the instant embodiment. Of the 1500 bytes, 40 bytes 
10 are utilized for the IP packet header The correspondent 
node is set as the IP header source address 614 and 
the mobile device is set as the IP header desiinatbn ad- 
dress 61 6. A total of 1460 bytes is available for data pay- 
bad 618. Once received at the node hosting the home 
15 agent 602. the home agent intercepts the IP packet 612 
on behalf of the mobile devrce 608. encapsulates the IP 
packet 612 with appended IP header destination and 
source addresses, and ton/vards the encapsulated 
packet 520 In an IP-in-IP tunnel to the foreign agent 610 
20 co-located at the mobile device 608. The encapsulated 
packet is therefore comprised of the original 40 byte IP 
header which included the correspondent node IP ad- 
dress 626 and the mobile device IP address 628. a ten 
byte appended IP header source address 622 designat- 
es ed with the home agent's IP address, a ten byte append- 
ed IP header destination address 624 designated with 
the foreign agent's IP address, and a total of 1440 bytes 
available for data pay load 630. When a tunneled encap- 
sulated packet 620 is received at the foreign agent 610. 
30 the foreign agent strips the appended I P header source 
and destination addresses 622.624 and delivers the re- 
mainder of the packet to the mobile device 608 for 
processing. 

[01 03] FIG. 20 is a diagram illustrating an optimization 

35 of the present invention used for tunneling IP packets 
from a mobile device's home agent to the mobile de- 
vice's foreign agent. Packets launched from a corre- 
spondent node 600 for delivery to a mobile device 608 
are firs! routed to a node hosting the home agent 602 of 

40 the mobile device 608. The home agent 602 is a regis- 
tered agent for the mobile device 608 to which all pack- 
ets having the nrx)bile device's IP address as a destina- 
tion address are first routed. The path between the cor- 
respondent node 600 and the home agent 602 is not 

45 Shown in its entirety. The Internet, private intranets, and/ 
or a plurality of routers and nodes may be interposed 
between the correspondent node 500 and the home 
agent 602. The home agent 602, upon receiving a pack- 
et having the mobile device's IP address as a destina- 

50 tion address forwards the packet to the mobile device's 
foreign agent 6i0, which in the instant embodiment is 
shown co-located at the mobile device 608. The mobile 
device 6i0 is shown maintaining an established wire- 
less connectbn with a base statton 606. A router 604 is 

55 shown interposed between the base statbn 606 and the 
home agent 602. The tunneling path between the home 
agent 602 and the mobile device 610 is not shown in its 
entirety. The Internet, private intranets, and/or a plurality 
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of routers and nodes may be interposed between the 
home agent 602 and the mobile device 608. 
[0104] An IP packet 612 conveyed from the corre- 
spondent node 600 for delivery to the mobile device 608 
is first received at a node hosting the home agent 602. 
The IP packet 612 is typically limited in size. 1500 bytes 
in the instant embodiment. Of the 1500 bytes, 40 bytes 
are utilized for the IP packet header. The correspondent 
node is set as the IP header source address 614 and 
the mobile device is set as the IP header destination ad- 
dress 6i6. A total of 1460 bytes is available for data pay- 
load SI 8. Once received at the node hosting the home 
agent 602. the home agent intercepts the IP packet 612 
on behalf of the mobile device 608. sand instead of en- 
capsulating the IP packet 612 with appended IP header 
source and destination addresses, interchanges the ad- 
dress assigned to the mobile device's foreign agent 644 
for the mobile device's IP address 6i6. Once the IP 
header destination address is interchanged, the new IP 
packet 640 is forwarded to the foreign agent 610 co-lo- 
cated at the mobile device 608. The new IP packet 640 
is therefore comprised of a 40 byte IP header which in- 
cludes the correspondent node*s IP address 642, the 
foreign agent's IP address 644. and 1460 bytes availa- 
ble for data paybad 646. Note that by swapping the 
packet's destination address instead of appending an 
additional IP header source and destination address, 
the available data payload 646 size is not adversely di- 
minished. That is. use of tunneling optimization reduces 
the overhead required for tunneling a packet from the 
honne agent to the foreign agent. When the new IP pack- 
et 640 is received at the foreign agent 610. the foreign 
agent interchanges the mobile device's IP address 616 
for the address assigned to the mobile device's foreign 
agent 644 and delivers the resulting packet to the mobile 
device 608 for processing. 

[01 05] FIG. 21 is a chart of a tcpdump trace for a con- 
ventional labile IP tunneling of packets. As previously 
described, when a mobile device is away from its home 
network, packets are typically tunneled from the corre- 
sponding home agent to the mobile device. If corre- 
spondent nodes were to utilize a route optimizatkyi ex- 
tension, packets may be routed directly to the mobile 
device without first being routed to a home agent How- 
ever, it will take a signifk:ant amount of time before cor- 
respondent nodes are upgraded to implement route op- 
timization. Conventk>nai Mobile IP tunneling of packets 
fronn the home agent to the foreign agent involves add- 
ing an additional header in each of the packets sent to 
the mobile device. Inclusion of this additional header 
presents serious and undesirable effects, as may be 
seen upon an examination of the tcpdump trace provkJ- 
ed in FIG. 21. Within the tcpdump trace, it is noted that 
the correspondent node is indicated by CH. the mobile 
device is indicated by MH. the home agent is indicated 
by HA, and the foreign agent is indicated by FA. 
[0106] The first five steps of FIG. 2l represent a 
Transmissk)n Control Protocol (TCP) handshake be- 



tween the correspondent node and the home agent dur- 
ing which it is determined that the maximum segment 
size (mss) is 1 460 bytes. The maximum segment size 
reflects the size of a payload portion of an IP packet in 

5 which application data reskJes. The remaining 40 bytes, 
out of the 1 500 bytes which comprise an IP packet, are 
utilized for the IP packet header which includes the 
source and destinaikjn IP addresses. In step six. when 
the first packet with a payk^d of 1 460 bytes is launched 

10 with the Donl Fragment Flag set (path MTU discovery), 
the home agent returns an Internet Control Message 
Protocol (ICMP) error message back to the correspond- 
ent node to indicate that the addition of a tunneling head- 
er wouU require fragmentation. After completion of step 

IS seven, a new path Maximum Transmission Unit (MTU) 
of 1 440 bytes is allocated tor packet payload. Therefore, 
in addition to the decreased packet transmissbn effi- 
ciency due to the inclusk)n of additional packet over- 
head, the utilizatbn of a tunneling header has the unde- 

20 sirable and inefficient effect of adding a wasted addition- 
al one round trip between the correspondent node and 
the home agent. This effect may be especially noticea- 
ble when utilizing the Mobile IP tunneling scheme for a 
web transfer from a correspondent node to a mobile de- 

2S vice, resulting in an additional delay of 500 milliseconds 
or more, since each web page transfer may require a 
plurality of TCP downkiads to complete the transfer. 
[01 07] FIG. 22 is a chart of a tcpdump trace for packet 
delivery from a home agent to a foreign agent utiUzing 

30 a tunneling optimization scheme in accordance with the 
present inventkan. As previously described, the tun- 
neling optimizaton utiPizes a foreign agent co-tocated 
with the mobile devu:e. therefore, a mobile device's 
care-of address is used as the mobile device's foreign 

35 agent address. Thus, the home agent may interchange 
the IP header destinatbn address from the mobile de- 
vce address to the co-located care-of address (foreign 
agent address). When the packet reaches the mobile 
devk:e. the co-bcated foreign agent substitutes the mo- 

40 bile device's IP address for the foreign agent address, 
thus restoring the packet header with the originally in- 
cluded fiekjs. The packet is then fonwarded to the appli- 
cation running on the mobile device. This tunneling op- 
timization scheme is completely transparent at the ap- 

45 pik:aiion layer and is applicable whenever the foreign 
agent is co-located with the mobile device. Further, the 
tunneling optimization incurs no additional header over- 
head. The first five steps of FIG. 22 represent a Trans- 
mission Control Protocol (TCP) handshake between the 

so correspondent node and the home agent. It is noted that 
steps two and Ave are generated by the home agent 
even though the IP packet header source address is that 
of the correspondent node. As is discernible with refer- 
ence to steps six through eight, an Internet Control Mes- 

55 sage Protocol (ICMP) error message requiring packet 
fragmentation is not needed, since no additional header 
is added. Therefore, use of tunneling optimization not 
only benefits packet transmission efficiency by reducing 
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the packet overhead required, but also eliminates the 
undesirable and inefficieni effect oi requiring an addi- 
tional one round trip per TCP session between the cor- 
respondent node and the home agent. 
(01 08] FIG. 23 is a flow diagram illustrating an exem- 
plary procedure for implementing a tunneling optimiza- 
tion at a node hosting a home agent In accordance with 
step 700. when a packet destined for the mobile device 
is received at the corresponding home agent, the IP 
header checksum is first checked to verify the accuracy 
of the IP header. The home agent maintains a list of mo- 
bite device addresses corresponding to mobile devices 
registered with the home agent which are away from 
home. This list is the Mobile Host A>Aey From Home List. 
In accordance with step 702. the home agent performs 
a check, via a table lookup, to see whetherthe IP header 
destination address for the instant packet has an asso- 
ciated entry in the Mobile Host Away From Home List. 
If not. then the tunneling optimization process is aban- 
doned and conventnnal IP processing is utilized to for- 
ward the packet. If the answer to the queiy of step 702 
is affirmative however, then step 704 is performed. In 
accordance with step 704, an IP Resen/ed Fragment 
Flag is set in the packet's IP header. The IP Resen/ed 
Fragment Flag being set indicates that the associated 
packet is subject to the instant tunneling optimization 
scheme. This important information is included within 
the packet's IP header so that the foreign agent receiv- 
ing the packet is informed that the tunneling optimization 
scheme has been utilized in conjunction with the packet 
received. In accordance with step 706. the mobile de- 
vice's address contained within the instant packet's IP 
header destination address is replaced with the care-of 
address associated with the mobile device. The care-of 
address in this case is the foreign agent's IP address, 
since the foreign agent is co-located at the mobile de- 
vice. In accordance wrth step 708. a new IP header 
checksum is calculated. A new checksum is cateulated 
since the instant IP header now includes the foreign 
agenf s IP address within the IP header destination ad- 
dress field, instead of the address of the mobile device. 
In accordance with step 710, the IP packet is then for- 
warded to the foreign agent which is co-located at the 
mobile device, 

[0109] FIG. 24 Is a flow diagram illustrating an exem- 
plary procedure for Implementing a tunneling optimiza- 
tion at a foreign agent co-located with a corresponding 
mobile device. In accordance with step 720, when a 
packet is received at the foreign agent, the IP header 
checksum is first checked to verify the accuracy of the 
IP header. In accordance with step 722. a check is made 
to determine whether the IP Reserved Fragment Flag, 
included within the IP header, is set. If the IP Reserved 
Fragment Flag is not set, then the instant packet has not 
been fonwarded to the foreign agent utilizing the tun- 
neling optimization scheme, and normal packet 
processing is implemented without altering the instant 
IP packet's destination address. If however, the Re- 



sen/ed Fragment Rag is set. it indicates that the tun- 
neling optimization scheme has been implemented at 
the home agent and must also be implemented at the 
co-tocaied foreign agent. Therefore, in accordance with 
5 step 724. the instant packet's IP header destination ad- 
dress is compared with entries in the foreign agent's co- 
located care-of address list. When the mobile devce 
first obtains a care-of address (which is the same as the 
foreign agent address when the foreign agent is co-to- 
10 cated with the corresponding mobile device), the foreign 
agent updates its care-of address list to reflect the cur- 
rent care-of address. Therefore, if the query made in 
step 724 returns a negative result, then the instant pack- 
et is receded in error and the packet is dropped, in ac- 
15 cordance with step 730. If however, the instant packef s 
IP header destinatkxi address matches an entry in the 
foreign agents co-located care-of address list, then step 
726 is performed. In accordance with step 726. the for- 
eign agent substitutes, in the instant packet's IP header 
20 destination address, the IP address corresponding to 
the home agent for the IP address corresponding to the 
foreign agent (I.e. - the care-of address). In accordance 
with step 728, packet processing for the instant packet 
is then resumed at the mobile device. 
2S [0110] The foregoing description merely illustrates the 
principles of the inventbn. It will thus be appreciated that 
those skilled in the art will be able to devise various ar- 
rangements which, although not explicitly described or 
shown herein, embody the principles of the invention 
30 and are included within its spirit and scope. Further- 
more, all examples and conditional language recited are 
principally intended expressly to be only for pedagogical 
purposes to aid the reader in understanding the princi- 
ples of the invention and the concepts contributed by 
3S the inventor(s) to furthering the art. and are to be con- 
strued as being without limitation to such specifically re- 
cited examples and conditions. Moreover ail state- 
ments herein reciting principles, aspects, and embodi- 
ments of the invention, as well as specific examples 
40 thereof, are Intended to encompass both structural and 
functional equivalents thereof. Additionally, it is intended 
that such equivalents include both currently known 
equivalents as well as equivalents devetoped In the fu- 
ture, i.e., any elements devetoped that perform the 
45 same function, regardless of structure. 

[0111] Thus, for example, it will be appreciated by 
those skilled in the art that the block diagrams herein 
represent conceptual views of illustrative circuitry em- 
bodying the principles of the invention. Similarly, it will 
so be appreciated that any flow charts, flow diagrams, state 
transition diagrams, pseudocode, and the like represent 
various processes which may be substantially repre- 
sented in computer readable medium and so executed 
by a computer or processor, whether or not such com- 
55 puter or processor is explicitly shown. 

[0112] The functions of the various illustrated or de- 
scribed elements, including functional blocks labeled as 
•processors." may be provided through the use of ded- 
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icated hardware as well as hardware capable of execut- 
ing software in association with appropriate software. 
Wher^ provided by a processor, the functions may be 
provided by a single dedicated processor, by a single 
shared processor, or by a plurality of individual proces* 5 
sors. some of which may be shared. Moreover, explicit 
use of the term 'processor* or 'controller* should not be 
construed to refer exclusively to hardware capable of 
executing software, and may implicitly include, without 
limitation, digital signal processor (OSP) hardware, >o 
read-only memory (ROM) for storing software, random 
access memory (RAM), and non-volatile storage. Other 
hardware, conventional and/or custom^ may also be in- 
cluded. Similarly, any switches shown in the figures are 
conceptual only. Their function may be carried out <5 
through the operation of program logic, through dedicat- 
ed logic, through the interaction of program control and 
dedicated logic, or even manually, the particular tech- 
nique being selectable by the implementoras more spe- 
ciHcaily understood from the context. ^ 



Claims 

1 . A method of providing wireless access to a packet- 
based network, said method comprising the steps 
of: 

defining a first domain, said first domain includ- 
ing a first group of base stations: 30 
providing a home agent for a wireless device 
within said first domain; 
assigning a first address for delivery of a plu- 
rality of packets to sakj wireless device, said 
first address utilized when said wireless device 3S 
is attached to said packet-based network 
through a base station included within said first 
domain; 

receiving, at said home agent, a second ad- 
dress for sakj wireless device when said wire- ^ 
less device is attached to said packet-based 
network through a base station excluded from 
said first domain; and 

tunneling said plurality of packets from said 
home agent to said second address for said 
wireless device if said wireless device is at- 
tached to said packet-based network through 
said base station excluded from saki first do- 
main. 

so 

2. The method in accordance with claim 1 wherein a 
plurality of packet routers are included within said 
first domain to interconnect sakl first group of base 
stations over a wired portion of said packet-based 
network. 55 

3. The method in accordance with claim 1 wherein 
said first address continues to be utilized for deliv- 



ery of said plurality of packets to sab wireless de- 
vice when said wireless device is handed off to any 
base statton included within said first domain. 

4. The method in accordance with claim i further com- 
prising the step of: 

updating routing table entries of said plurality 
of packet routers and sakj first group of base sta- 
tions within said first domain utilizing path setup 
messages. 

5. The method in accordance with claim 1 wherein 
said first domain is a subnet using a common local 
protocol for signaling and messaging within said 
subnet. 

6. The method in accordance with claim 1 wherein 
said first address is associated with satd wireless 
device for as long as sakJ wireless device Is at- 
tached to a base station included within sakj first 
domain. 

7. The method in accordance with claim 6 wherein 
routing table entries corresponding to said first ad- 
dress at said packet routers and sakj first group of 
base stations are updated to fonward sakj plurality 
of packets to said wireless device whenever sakf 
wireless device is attached to said packet-based 
network through one of said first group of base sta- 
tions. 

8. A method of provkjing mobile device access to a 
packet-based network from a plurality of base sta- 
tions adapted for packet routing via a plurality of 
routers attached to sakj packet-based network, saki 
method comprising the steps of: 

defining a first domain, said first domain includ- 
ing a first group of said plurality ol base stations 
interfaced with said packet-based network via 
a first group of said plurality of routers; 
assigning a first address for delivery of a plu- 
rality of packets to a mobile device, said first 
address corresponding to said mobile device 
and utilized whenever saic mobile device is at- 
tached to said packet -based network through 
one of said first group ol said plurality of base 
stations: and 

updating a routing table entry corresponding to 
sakj first address in selected ones of said first 
group of said plurality of routers and said first 
group of said plurality of base stations to spec- 
ify a routing path through said first group of said 
plurality of routers and said first group of said 
plurality of base statbns for delivery of sakj plu- 
rality of packets to said mobile device, regard- 
less of the one of said first plurality ol base sta- 
tions through which sakj mobile device is at- 
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tached to said packet-based network. 

The method in accordance with claim 9 further com> 
prising the steps of: 

5 

designating a router, from sakJ first group of 
said plurality of routers, as a root router, 
defining a second domain, said second domain 
including a second group of sakJ plurality of 
base stations interfaced with said packet- io 
based network via a second group of said plu- 
rality of routers: 

assigning a secorxl address for delivery of sasti 
plurality of packets to said mobile device; 
conveying said second address to sakj root 
router, and 

tunneling said plurality ot packets from said root 
router, through at least one selected router from 
sak) second group of sakJ plurality of routers, 
through one of said second group of said piu- ^ 
rality of base stations, and to said mobile de- 
vice, when sakl mobile device is attached to 
said packet-based network through said one of 
said second group of said plurality of base sta- 
tkjns. 2* 
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